Sicurezza e privatezza

1. Storia della Computer Security

Anni ‘70 – Mainframe

I mainframe venivano usati principalmente in ambienti militari e governativi e possedevano dei sistemi

multi-utente. Era perciò necessario far sì che gli utenti fossero tra loro separati, eccezion fatta per i dati

condivisi quando necessario, e che non fossero in grado di interferire con la gestione del sistema.

I principali problemi riguardano:

 Crittografia come protezione dei dati salvati in memoria (DES – Data Encryption Standard)

 Query a database

 Privacy

Anni ‘80 – Personal Computer

I computer divennero poi molto più piccoli, più facili da utilizzare (grazie alle GUI) e più economici, al punto

di poter essere acquistati da utenti singoli senza dover passare dall’IT department. A questo punto la

sicurezza multi-utente non serviva più.

Principali problemi:

 Worm: attacchi automatici in grado di autocopiarsi sulla macchina infetta e diffondersi nella rete

 Virus: malware che infettano dei file e danneggiano il software della macchina che li ospita

1988: primo worm (Morris), sfrutta buffer overflow, debolezze delle password e della configurazione del

sistema.

Anni ‘90 – Internet

Internet diventa una tecnologia disponibile a tutti ed aperta all’uso commerciale.

Principali problemi:

 Come sistema di comunicazione necessita di crittografia per proteggere le conversazioni

 I PC non sono più entità a sé stanti, ma sono tra loro connessi tramite Internet: non si può più

controllare chi invia cosa alla macchina (problemi di identificazione e buffer overrun)

 Digital Rights Management (DRM) per la tutela dei diritti d’autore in ambito digitale

 Attacchi DOS (Denial Of Service) vengono combattuti tramite firewall e intrusiondetection system

 Protocolli sicuri: IPsec, SSL/TLS

 Sandbox: prigione in cui viene eseguita un’applicazione al fine di limitare il numero di operazioni che

può fare

Anni 2000 – Web

Sebbene la tecnologia del web risalga agli anni ’90, nei 2000 aumenta il numero di persone che lo

utilizzano, principalmente privati, con un accesso regolare. In questo modo le compagnie sono in grado di

mettersi in contatto diretto con i consumatori, dando il via all’e-commerce.

Cambia anche il tipo di attaccante: negli anni ’90 gli attacchi venivano fatti da hacker, in genere ragazzi che

volevano dimostrare la loro abilità in ambito informatico, ma nei 2000 si vengono a formare delle vere e

proprie organizzazioni criminali con lo scopo di rubare dati sensibili o di utilizzare i computer delle vittime

all’interno di botnet (aggregazioni di computer compromessi) al fine di guadagnare denaro. Tuttavia, non

solo i cyber criminali sono autori di attacchi informatici, ma anche attivisti e governi.

Principali attacchi:

 SQL injection: attacchi a database

 Cross-site scripting al fine di rubare le credenziali di un utente

 Attacchi al DNS per fare reindirizzamento sostituendo l’indirizzo IP

 Attacchi APT (Advanced PersistentThread): attacchi rivolti ad un target specifico (es.: per spionaggio)

3. Fondamenti della Computer Security

Strategie di sicurezza

Classificazione delle strategie di sicurezza:

 Prevention (prevenzione): sistema che prende delle misure per prevenire l’attacco, ovvero in grado di

bloccarlo prima che questo avvenga

 Detection (rilevazione): sistema che rileva l’attacco nel momento in cui avviene

 Reaction (reazione): sistema in grado di reagire all’attacco e di ristabilirsi

Obiettivi di sicurezza

Obiettivi di sicurezza:

 Confidentiality (riservatezza): prevenire l’esportazione delle informazioni da parte di chi non è

autorizzato (prevenire la lettura di dati senza autorizzazione)

- Privacy: protezione dei dati personali

- Secrecy: protezione dei dati di un’organizzazione

 Integrity: prevenire la modifica di informazioni da parte di chi non ne ha l’autorità (prevenire la

scrittura di dati senza autorizzazione)

 Availability (disponibilità): proprietà di essere sempre disponibile e accessibile

Problemi:

- Denial of Service (DoS): impedire che gli utenti legittimi possano accedere al sistema (ad

esempio, saturando la banda con continue richieste)

- Distributed Denial of Service (DDos): DoS che utilizza una botnet

- Smurfattack: l’attaccante invia dei pacchetti di rete ICMP echo in broadcast con l’IP sorgente

della vittima (addressspoofing), così che tutte le risposte arrivino alla vittima, saturandone la

banda (flooding)

 Authenticity: si conosce l’identità di chi fa ogni azione

 Accountability (non-repudiation):

 Accountability (responsabilità): log di controllo che permettono di registrare ed identificare le azioni

che sono state fatte e le identità associate ad esse (gli utenti sono responsabili delle loro azioni)

 Non-repudiation: fornire prove evidenti che una specifica azione è avvenuta (ciò non significa che

siano inconfutabili)

Altre proprietà meno collegate alla sicurezza:

 Reliability (affidabilità): il software viene testato secondo le operazioni di utenti normali, è quindi

connessa a problemi accidentali e più comuni. Per far sì che il software sia sicuro è però necessario

testarlo anche secondo pattern non comuni (che vengono utilizzati per gli attacchi)

 Safety: misura l’assenza di influenze catastrofiche sull’ambiente (sicurezza fisica)

Principi della Computer Security

Dimensioni della Computer Security:

Decisioni fondamentali di design:

1. Dove focalizzare i controlli di sicurezza?

Il focus può essere posto su:

 Dati: formato e contenuto dei dati

 Operazioni che possono essere fatte sui dati

 Utenti: dati a cui i vari tipi di utenti possono accedere

2. Dove mettere i controlli di sicurezza?

Man-machine scale: scala dall’utente verso la macchina (modello a cerchi di protezione o a cipolla)

I software maggiormente esposti agli attacchi sono il web browser e le e-mail (applicazioni), ma

andando sempre più verso l’hardware la superficie di attacco diminuisce. Tuttavia, spostarsi verso

l’hardware comporta uno svantaggio: la semantica dei dati ha poco significato, mentre in user-space

essa è molto più ricca di informazione. Ciò comporta che i meccanismi hardware siano molto più

generici rispetto a quelli nei livelli più esterni.

3. Conviene adottare meccanismi semplici oppure complessi?

Meccanismi generici (spostati verso l’hardware, secondo il modello man-machine scale) sono più

semplici e portano ad una maggiore garanzia di sicurezza, mentre meccanismi più specifici danno un

più alto numero di feature di sicurezza, ma sono anche più complessi.

4. Sistema di difesa centralizzato o decentralizzato?

 Sistema centralizzato: avere una singola entità che si occupa della sicurezza del sistema rende

semplice raggiungere uniformità (tutto il sistema segue la stessa policy), tuttavia può diventare un

collo di bottiglia a livello di performance

Es. Antivirus con database all’interno della macchina

 Soluzione distribuita: più efficiente, ma bisogna garantire che tutte le componenti abbiano una policy

consistente

Es. Smartphone: i dati e le informazioni di sicurezza vengono inviati ad un server

5. Come bloccare l’accesso al livello sottostante (layerbelow)?

Ogni meccanismo di protezione definisce un perimetro di sicurezza, all’interno del quale risiede la

parte di sistema che può disabilitare il meccanismo. Ciò che cerca di fare l’attaccante è di accedere

all’interno del perimetro passando da una strada non controllata (che passa per i livelli sottostanti), è

perciò necessario controllare e bloccare queste strade alternative.

Esempi di accesso al layerbelow:

 Recovery tools: permettono di recuperare file cancellati leggendo direttamente la memoria.

Questi tool possono essere utilizzati per eludere il controllo logico di accesso, poiché ignorano la

struttura logica di memoria

 Unix considera i device di I/O come dei file: se si definiscono male i permessi di accesso,

l’attaccante può fare azioni che non dovrebbe

 Buffer overrun: il valore assegnato ad una variabile supera la dimensione del buffer allocato per

quella variabile, quindi la variabile viene scritta oltre ai limiti, sovrascrivendo altri dati

 Object reuse: quando avviene un context switch in un sistema monoprocessore potrebbe

accadere che ci siano degli storage residues, ovvero dati lasciati nella memoria dal processo

precedente. Se il nuovo processo potesse leggere tali dati, non ci sarebbe più separazione logica

tra i processi

 Backup: chiunque abbia accesso al backup ha accesso ai dati che contiene

 Core dumps: quando in sistema crasha crea un core dump del suo stato interno. Se tali fossero

contenuti in file accessibili a chiunque, un attaccante potrebbe avere accesso ad informazioni

riservate

 Side channelanalysis: attacco che mira ad ottenere informazioni osservando le conseguenze

dell’implementazione fisica di un meccanismo di crittografia, come il consumo energetico,

informazioni sui tempi, …

 SSL: messaggi che possono essere decifrati calcolando i tempi di risposta dei server SSL

6. Reference Monitors

Reference Monitor, Security Kernel e TCB

 Reference monitor: sistema che media gli accessi

 Security kernel: elementi hardware, firmware e software che implementano il concetto di reference

monitor

 Trusted Computing Base (TCB): insieme dei meccanismi di protezione di un computer la cui

combinazione fa valere la politica di sicurezza

Il reference monitor è un concetto astratto, il security kernel è la sua implementazione e il TCB contiene il

security kernel ed altri meccanismi di protezione (TCB: insieme di tutte le componenti che fanno parte del

reference monitor). Più piccola è la TCB e meglio è. Tutte le componenti della TCB sono da considerare

trusted.

Posizionamento del Reference Monitor

Il reference monitor può essere posto in diversi livelli:

 Hardware: circuiti di sicurezza nei microprocessori

 Kernel o hypervisor (livello -1): l’hypervisor è una macchian virtuale che emula il computer su cui gira

e può essere usato per separare utenti o applicazioni, fornendo a ciascuno una macchina virtuale

 Sistema operativo (livello 0): controllo degli accessi

 Librerie: controllo degli accessi nei database, nella Java Virtual Machine (JVM), …

 Applicazioni: controlli di sicurezza nel codice delle applicazioni

Posizionamento del reference monitor rispetto al programma che controlla:

 RM nel kernel: codice che intercetta tutte le system call del processo

 RM nell’interprete: l’interprete media tutte le richieste di accesso fatte dal programma (es. JVM)

 RM all’interno del programma (in-line RM): i controlli sono all’interno del codice del programma

La terza soluzione è quella più veloce (la velocità di esecuzione dei controlli è pari alla velocità di esecuzione

del programma), mentre la prima è quella più lenta (ogni volta che viene fatta una system call si deve fare

un contest switch per eseguire il controllo). Tuttavia, il modello più sicuro è invece il primo: gli altri due

sono in user-space e per questo sono maggiormente esposti agli attacchi.

Integrità del sistema operativo

Anche il sistema operativo in sé è un oggetto di controllo degli accessi, pertanto non deve poter essere

modificato dagli utenti.

Requisiti di un sistema operativo sicuro:

 Gli utenti devono essere in grado di invocare alcune operazioni del sistema operativo

 Gli utenti non devono essere in grado di fare un uso sbagliato del sistema operativo

Concetti fondamentali:

 Modes of operation: quali azioni possono essere eseguite sul sistema.

Un sistema può lavorare in:

- User mode: si possono fare solo operazioni che non sono critiche per la sicurezza

- Supervisor mode: possono essere eseguite anche delle operazioni privilegiate che non possono

essere eseguite in user mode

Per sapere in che modalità si sta eseguendo, l’informazione viene salvata in un registro hardware

(status flag)

 Invocazioni controllate (o privilegi ristretti): quando un utente vuole eseguire un’operazione che

richiede la supervisor mode, è necessario cambiare modalità.

Feature di sicurezza nei microprocessori

La cosa migliore è porre i sistemi di sicurezza negli strati più bassi del sistema:

 È ragionevolmente semplice per implementare meccanismi di sicurezza senza eccessiva difficoltà

 Riduce l’overhead causato dalla sicurezza tramite un’attenta scelta di un set di operazioni di sicurezza

particolarmente utili

Gestione della memoria

Tipi di memoria:

 Volatile: perde il suo contenuto quando il computer viene spento, ma può succedere che parte del

contenuto sia ancora presente al riavvio o che possa essere ricostruito tramite tecniche elettroniche.

Per evitare ciò è necessario sovrascrivere la memoria svariate volte con un determinato pattern di bit.

 Non volatile: la memoria conserva il suo contenuto anche dopo che il computer è stato spento. È

pertanto necessario prendere delle misure di sicurezza a livello crittografico o fisico, poiché un

attaccante potrebbe bypassare il controllo della CPU.

Esempi storici: Intel 80386/80486

4 livelli di privilegio:

 0: sistema operativo

 2: user space

 1 e 3: macchine virtuali

Le informazioni riguardanti gli oggetti del sistema sono contenute in decriptors, all’interno di una

descriptortable e possono essere acceduti tramite dei selettori, campi da 16 bit contenenti l’indice della

tabella e il RPL.

Si definiscono i seguenti campi:

 RPL (RequestedPrivilege Level): livello di privilegio del software chiamante

 CPL (CurrentPrivilege Level): livello di privilegio del codice che è correntemente in esecuzione

 DPL (DesriptorPrivilege Level): livello di privilegio necessario per accedere ad una determinata risorsa

contenuta nella descriptortable

Per accedere alla tabella si utilizza un selettore contenete CPL, si controlla quindi che sia    (chi

accede deve avere un permesso maggiore o uguale a quello richiesto dalla risorsa: permessi maggiori

corrispondono a livelli di permesso minori).

L’invocazione controllata viene fatta attraverso una system call: il processo chiamante si trova in user mode

(livello 2), ma è poi il sistema operativo (livello 0) che, eseguendo la richiesta, accede alla risorsa. In questo

caso si ha RPL=2 e CPL=0.

Gate: oggetto di sistema che punta ad una procedura che ha un livello di privilegio differente dal gate

stesso. Permette l’esecuzione di procedure di livello inferiore da parte di una procedura che si trova allo

stesso livello del gate. Quando una procedura invoca un subroutine attraverso ad un gate, il CPL (che

inizialmente ha lo stesso valore di RPL) cambia e diventa il livello del codice a cui il gate punta. Alla fine CPL

torna uguale a RPL (non può mantenere il privilegio anche dopo).

ConfusedDeputyProblem

Una procedura con permessi più bassi potrebbe chiedere ad una con permessi più alti di copiare degli

oggetti con alto privilegio in una zona di memoria a basso privilegio alla quale può accedere.

AdjustRequestedPriviledge Level (ARPL): istruzione che imposta gli RPL di tutti i selettori uguali ai CPL dei

processi chiamanti. Il sistema compara poi gli RPL nei selettori con i DPL nei descrittori.

Protezione della memoria

Per far sì che i processi siano tra loro indipendenti è necessario che ciascuno di essi sia confinato in uno

spazio di indirizzamento separato.

3 opzioni per controllare l’accesso alla memoria:

 Il sistema operativo modifica gli indirizzi che riceve dal processo utente.

Es.: Addresssandboxing: gli indirizzi consistono in un identificatore ed in un offset. Quando al sistema

operativo arriva un indirizzo, viene fatta una AND bit a bit tra l’indirizzo ed una maschera che cancella

l’identificatore, dopo di che si fa una OR bit a bit con un’altra maschera che mette l’identificatore

dell’indirizzo corretto (operazione svolta dalla MMU).

 Il sistema operativo costruisce gli indirizzi effettivi dagli indirizzi relativi che riceve dal processo

utente.

Indirizzo relativo: offset a partire da un indirizzo base. Il sistema operativo utilizza gli indirizzi relativi

per calcolare gli indirizzi effettivi sommando ad essi l’indirizzo base del programma, controllando che

il risultato sia all’interno dello spazio accessibile dai programmi utente.

 Il sistema operativo controlla se l’indirizzo che riceve dal processo utente è interno ai confini della

porzione di memoria affidata a quel processo

Es.: Motorola 68000 functioncodes: indicano lo stato del processore così che il decoder degli indirizzi

potesse scegliere tra memoria utente e memoria supervisor.

Sandbox (prigione): la memoria viene divisa in finestre, ognuna visibile solo ad un processo

 Do al processo una partizione limitata del file system

 Do una limitazione alle operazioni che il processo può fare

4. Identificazione e autenticazione

Autenticazione degli utenti

Un sistema sicuro deve poter tracciare le identità degli utenti che fanno uso dei suoi servizi:

 L’identità dell’utente è un parametro d’accesso alle decisioni di sistema: permette di associare

l’utente ad una persona vera e propria tramite autenticazione

 L’identità dell’utente permette di loggare le operazioni che svolge

Identificazione e autenticazione

Fasi:

1. Identificazione: l’utente annuncia chi è (username)

2. Autenticazione: processo per verificare l’identità di un utente (password)

Password

Bootstrapping password

Processo di bootstrapping: come viene creata la password per la prima volta.

 L’utente va fisicamente dall’amministratore di sistema che ne controlla l’identità e fa creare la

password

 Creazione della password da remoto: è possibile farlo su più canali, come e-mail, telefono, …

Password dimenticate

Le password vengono facilmente dimenticate, quindi serve un modo per poterle recuperare o resettare.

Per far ciò viene in genere fatta una domanda di sicurezza alla quale solo il vero utente dovrebbe saper

rispondere. Se la risposta è corretta la password viene mandata per e-mail (ciò però significa che è salvata

in chiaro sul sistema), oppure viene inviato un link per crearne una nuova (più sicuro).

Password guessing

Diverse tecniche per indovinare la password di un utente:

 Brute force: si provano tutte le possibili combinazioni dei simboli validi fino ad una certa lunghezza

 Intelligentsearch: si prova un ristretto numero di possibili password che potrebbero essere in qualche

modo associate all’utente (esistono delle password o dei pattern che sono particolarmente popolari)

 Attacchi dizionario: si provano tutte le password contenute in un dizionario (è possibile trovarli on-

line)

Protezioni da questi attacchi:

 Cambiare la password di default

 Utilizzare password lunghe e con caratteri di diverso tipo (maiuscole, minuscole, numeri e caratteri

non alfabetici): il brute force dipende dalla lunghezza della password e dall’alfabeto. Bisogna però

evitare password eccessivamente complesse che non si riescono a ricordare, perché scriverle da

qualche parte potrebbe essere altrettanto pericoloso

 Definire un tempo di scadenza dopo il quale si richiede di modificare la password ed impedire agli

utenti di utilizzare password già usate in precedenza. Anche memorizzare in continuazione password

differenti può essere complicato per gli utenti

 Dare un limite ai tentativi di log-in: il brute force consiste nel provare tutte le possibili combinazioni,

ma in questo modo non può provarle tutte

 Informare l’utente sul numero di tentativi falliti prima di riuscire a fare il log-in

Password manager: applicazione che mantiene traccia di tutte le password sul sistema. È protetto da

un’unica password che funziona come chiave di cifratura per le altre. Quando si vuole loggare ad un sito, il

password manager cerca la password salvata in cloud ed accede automaticamente.

Password spoofing

Spoofing: l’attaccante avvia un programma che presenta un finto login che impersonifica il vero sistema di

autenticazione. Quando poi l’utente inserisce le sue credenziali, queste vengono catturate dal programma,

che mostra poi un finto messaggio di errore e ritorna al vero sistema.

Contromisure:

 Mostrare il numero di login falliti

 Trustedpath: modo sicuro in cui è possibile interfacciarsi con la schermata di login

Es.: Windows: CTRL+ALT+CANC (per modificare il programma a cui punta, si dovrebbe accedere alla

Interrupt DescriptionTable, ma se si riesce ad arrivare a questo punto ci sono altri modi per

recuperare le password)

 Mutualauthentication: anche il sistema deve identificarsi verso l’utente

Phishing: l’attaccante impersonifica il sistema per convincere l’utente a rilasciargli la password. In genere si

invia una e-mail all’utente chiedendo di inserire le proprie credenziali su un sito finto creato ad hoc per

essere scambiato per quello originale.

Social engineering: l’attaccante si finge un operatore e contatta l’utente per chiedergli la password al fine di

fare dei controlli fasulli.

Compromettere il file delle password

I sistemi operativi salvano in un file gli username e le password degli utenti (Unix: /etc/shadow). Un

attaccante potrebbe voler accedere a questo file, compromettendone la confidenzialità e l’integrità,

pertanto tale file deve essere protetto:

 Crittografia

 Permessi di accesso

One-way function (hashfunction): dato un input x genera un output f(x), ma dato un output y è difficile

trovare una x tale che y=f(x) (non si riesce a tornare indietro dall’output all’input). Nel file delle password si

salva il valore f(x) corrispondente alla password x ed ogni volta che un utente cerca di loggare si calcola la

hash della password che inserisce e si confronta il risultato al contenuto del file.

Password salting: si aggiunge un salt alla password prima che questa vada in input alla funzione di hash. In

questo modo, se due utenti avessero la stessa password avrebbero comunque due hash della password

diversi.

Sistemi biometrici

Si può essere autenticati sulla base di:

 Qualcosa che si conosce (es.: password, informazioni personali, …): chiunque conosce il segreto è

considerato come il proprietario dell’account e non ci sono prove del passaggio di tale segreto a

qualcun altro

 Qualcosa che si possiede (es.: chiavi, carte, smartcards, …): oggetti fisici possono essere perso o

rubati, pertanto sono solitamente utilizzati in combinazione con qualcosa che si conosce (es.: PIN)

 Chi si è: le tecniche biometriche utilizzano delle caratteristiche fisiche (es.: impronte digitali, iride, …)

per identificare una persona. Non sono tuttavia deterministiche, ma bensì soggette ad errori:

- Falsi positivi: capita che vengano accettate le persone sbagliate (problema di sicurezza)

- Falsi negativi: può succedere che neghi l’accesso ad utenti legittimi (problema di inefficienza)

Queste caratteristiche sono uniche, ma non sono dei segreti: le impronte digitali vengono lasciate in

giro di continuo

 Cosa si fa (es.: scrittura a mano)

 Dove si è (es.: accesso solo da un determinato terminale, GPS)

7. Unix Security

Unix security – background

Obiettivi della sicurezza di Unix:

 Proteggere gli utenti l’uno dall’altro

 Proteggere gli utenti da attacchi provenienti dalla rete

Principi, soggetti, oggetti

Principi

Principi:

 UID (user identifier): numero a 16 bit che identifica un utente, o 0 corrisponde sempre al superuser

(root)

 GID (group identifier): numero a 16 bit che identifica un gruppo

Queste informazioni sono contenute nel file /etc/passwd, in particolare a ciascun account corrisponde

una stringa (account format): username:password:UID:GID:name:homedir:shell

Le informazioni inerenti ai gruppi sono invece contenute nel file /etc/group, le cui entry sono del

formato: groupname:password:GID:list of users. Ogni utente appartiene ad un gruppo primario, tuttavia

può appartenere a più di un gruppo. Gli utenti che appartengono allo stesso gruppo sono soggetti alle

stesse regole.

Soggetti

In Unix i soggetti sono i processi, a ciascuno dei quali è associato un identificativo (PID – processidentifier). I

processi hanno diversi tipi di UID/GID:

 UID/GID reale: vengono ereditati dal genitore e sono il UID ed il GID dell’utente che lancia

l’applicazione in quel momento

 UID/GID effettivo: UID e GID effettivi che vengono utilizzati per l’accesso alle risorse

 UID/GID salvato: serve per poter tornare indietroal UID/GID originale

Es.:

Il file /etc/passwd può essere letto da molti programmi che hanno bisogno dei dati degli account. Per

questa ragione le password non sono salvate in /etc/passwd, ma in /etc/shadow, un file che può

essere accessibile solo da root.

Oggetti

In Unix gli oggetti su cui si possono fare delle operazioni si chiamano risorse e sono tutte rappresentati

come file. Sono organizzate in una struttura ad albero (file system) cui ogni nodo (directory o i-node)

contiene informazioni relative ai file che punta, comprese quelle di controllo d’accesso:

 Carattere che indica il tipo del file:

- -: file semplice

- d: directory

 Permessi: 9 caratteri divisi in triplette, ognuna delle quali fa riferimento a degli utenti:

- Prima tripletta: permessi del proprietario del file

- Seconda tripletta: permessi del gruppo del proprietario

- Terza tripletta: permessi per tutti gli altri

Ogni tripletta rappresenta tre diversi tipi di permesso (se non si ha un permesso allora c’è un -):

- r (read): permesso di lettura del file (o di cercare file nella directory)

- w (write): permesso di scrittura del file (o di aggiungere/rimuovere file nella directory)

- x (execute): permesso di eseguire il file (o di aprire i file presenti nella directory)

 Link counter: numero di riferimenti a questo file

 Username del proprietario (in genere l’utente che lo ha creato)

 Nome del gruppo del proprietario

 Dimensione del file

 Data dell’ultima modifica

 Nome del file

Es.:

Altri permessi che possono essere aggiunti:

 set UID (SUID): permette di modificare l’effective UID (se servisse avere dei permessi maggiori)

 set GID (SGID): permette di modificare l’effectiove GID

 sticky bit (S): viene utilizzato nelle directory temporanee dove tutti hanno tutti i permessi, serve per

impedire che un utente cancelli un file di cui non è proprietario

Rappresentazione ottale: per rappresentare 3 bit bastano 8 numeri in decimale (0-7), pertanto è possibile

scrivere ciascuna tripletta di permessi con un numero e tutti i permessi con 3.

Es.: rw-r--r--equivale a 110 100 100 in binario ed a 644 in decimale.

Viene aggiunto poi in testa un quarto numero a rappresentare i tre permessi che possono essere aggiunti:

 4: set UID

 2: set GID

 1: set sticky bit

Comandi:

 chmod: permette al proprietario del file di modificare i permessi (es.: chmod 0754 filename)

 chowm: permette a root di modificare il proprietario del file (es.: chownnOwner:nGroupfilename)

Di default vengono dati i permessi 666 alla creazione di un file e 777 alla creazione di una nuova directory.

Tali possono essere poi modificati utilizzando la umask (numero ottale di 3 cifre rappresentati i permessi

che devono essere negati) in AND bit a bit con i permessi di default.

Security pattern

Invocazioni controllate (programmi SUID)

I programmi SUID girano con lo user ID del loro proprietario, dando accesso controllato ai file che

normalmente non potrebbero essere acceduti da altri utenti, ma che possono farlo eseguendo il

programma.

Quando si mostrano i permessi di un programma SUID, al posto della x del proprietario viene mostrata una

s (minuscola). Analogamente, per i programmi SGID il permesso di esecuzione x del gruppo viene sostituito

con una S (maiuscola).

Un attaccante potrebbe eseguire un programma SUID il cui proprietario è root per accedere ai permessi del

superuser e fare azioni inaspettate. Per questa ragione bisogna processare questi programmi con estrema

cura, controllando gli input e monitorando l’integrità del programma.

Rappresentazione fisica e logica degli oggetti: cancellare i file

Cosa succede quando viene cancellato un file?

 Cancellazione logica: può succedere che, quando viene cancellato un file, si cancelli in realtà solo una

istanza del file stesso, ma questi potrebbe avere delle copie che continuano a persistere. Se il file non

ha copie, la memoria che era prima allocata ad esso diventa ora nuovamente disponibile, tuttavia,

finché effettivamente non viene sovrascritta, continua a contenere il file cancellato

 Cancellazione fisica: è possibile fare una rimozione vera e propria del file sovrascrivendo il suo

contenuto con un pattern apposito

Accesso al layerbelow: mettere al sicuro la memoria ed i dispositivi

Unix considera i dispositivi come file: accedere ad un dispositivo è come accedere ad un file. I dispositivi si

trovano nella directory /dev. Alcuni di questi file sono molto pericolosi dal punto di vista della sicurezza

(es.: /dev/kmem contiene la mappa della memoria del kernel, /dev/hd0 è invece l’hard disk). Se i

permessi non fossero settati a dovere, l’attaccante potrebbe accedere o modificare questi dati.

Importare i dati: file system montati

È possibile montare file system creati esternamente, questo significa che il file system remoto viene

agganciato all’albero principale e il tutto viene visto nel sui insieme.

Problema: nel file system remoto possono esserci dei controlli di accesso pericolosi, come dei programmi

con SUID-root per poter avere i permessi del superuser una volta collegati al file system principale. È

dunque necessario eseguire il comando mount con delle opzioni di sicurezza:

 -r: read-onlymount

 nonsuind: disattiva i bit SUID e GID del file system montato

 nonexec: impedisce l’esecuzione di file binari

 nodev: impedisce l’accesso a device

Variabili d’ambiente

Variabili d’ambiente: variabili utilizzare per configurare il comportamento di un programma. Quando viene

creato un processo, esso eredita di default le variabili d’ambiente del processo padre, ma possono essere

poi modificate da un altro programma. Questo può essere un problema poiché il chiamante di un

programma SUID/SGID è in controllo delle sue variabili d’ambiente e potrebbe impostarle a valori

pericolosi.

Il controllo degli accessi potrebbe essere implementato facendo girare i processi sospetti all’interno a delle

sandbox: in genere un programma ha visione di tutto il file system, a partire dalla root directory. Tuttavia,

una sandbox crea un ambiente minimale contenente solo i file strettamente necessari all’esecuzione del

programma, riducendo la visione che esso ha del file system.

Per creare una sandbox si utilizza il comando chroot (change root), che fa vedere ad un programma la

directory indicata come root (non può risalire l’albero oltre a quella directory).

Path di ricerca: possibile eseguire un programma scrivendo il suo nome senza specificare il suo path

(posizione del programma all’interno del file system). La shell cerca il programma seguendo i path

specificati all’interno delle variabili d’ambiente. Quando trova una directory che contiene il programma col

nome specificato lo esegue.

Per inserire un Trojan (malware che si nasconde all’interno di un programma apparentemente innocuo) è

necessario dargli lo stesso nome di un programma esistente ed inserirlo all’interno della directory che viene

controllata prima di quella contente il programma originale.

Wrapper

Inetd (InterNETservicesDaemon): servizio di rete che sta in ascolto di connessioni alla rete (TELNET).

Quando viene fatta una connessione, inetd controlla il file di configurazione e crea un nuovo processo con

lo stesso nome del chiamante che esegue un programmwrapper che esegue dei controlli di sicurezza. Se i

controlli vengono superati allora si procede con l’esecuzione della connessione effettiva.

Gestione della sicurezza di Unix

Proteggere l’account root

Se un attaccante riesce ad ottenere lo status del superuserpuò prendere il controllo di tutto il sistema,

pertanto è essenziale proteggerlo al meglio.

Accorgimenti per prevenire questo problema:

 Dividere i compiti di mantenimento del sistema tra più utenti: se un utente fosse compromesso non

lo sarebbe l’intero sistema, ma solo quello che lui è in grado di controllare

 L’amministratore di sistema non dovrebbe usare root come suo account principale

 Quando bisogna cambiare utente per diventare root conviene specificare l’intero path del comando

(/bin/su): evitare possibili variabili d’ambiente compromesse

 Registrare tutti i tentativi di esecuzione del comando su in un file di log

 Proteggere /etc/passwd e /etc/group con permessi che impediscono la scrittura: in questo

modo un attaccante non può impostare il suo UID a 0

Trustedhost

Gli utenti provenienti da un trustedhost possono loggarsi al sistema senza password, ma è sufficiente che

abbiano lo stesso username su entrambi gli host. Tali sono salvati nel file /etc/hosts.equiv.

Audit log

Non sempre i meccanismi di difesa di un sistema sono sufficientemente adeguati, quindi ci sono dei file di

log per registrare automaticamente alcuni eventi rilevanti a livello di sicurezza (audit log):

 /usr/adm/lastlog: registra quando ciascun utente ha effettuato il login l’ultima volta

 /var/adm/utmp: registra le informazioni del comando who (mostra tutti gli utenti collegati

correntemente al sistema)

 /var/adm/wtmp: registra tutti i tempi di quando un utente fa login e logout

 /var/adm/acct: registra tutti i comandi eseguiti

10.aAttacchi software

Sicurezza software

Sicurezza software: proteggere l’integrità del sistema runtime.

Il software è sicuro se riesce a gestire degli input appositamente malformatiBisogna considerare gli accessi

al programma come untrusted ed applicare dei filtri.

Modelli di visualizzazione del software:

 Black box: non si conosce niente, ma è possibile dare degli input ed osservarne il comportamento

 White box: è possibile vedere l’applicazione anche internamente

Reliability (affidabilità): il software deve comportarsi bene rispetto all’utilizzo dell’utente medio, ovvero

deve evitare fallimenti accidentali dovuti ad azioni che ci si potrebbe aspettare.

Sicurezza: il software deve saper reagire anche a utilizzi atipici (ma tipici per gli attaccanti) e pericolosi.

Pericolo di astrazione

Quando scrivono codice, i programmatori usano concetti elementari con un significato astratto, ma per

eseguire un programma sono necessarie delle implementazioni concrete di questi concetti. I problemi di

sicurezza software insorgono nel momento in cui l’implementazione concreta e l’intuizione dovuta

all’astrazione divergono.

Es.: il programmatore può pensare che un intero sia un numero infinito, ma in realtà una macchina lo

rappresenta con un numero finito di bit.

Validazione dell’input

Es.: un’applicazione vuole dare accesso agli utenti solo alla directory A/B/C e si aspetta che l’utente medio

inserisca il nome del file come input. Un attaccante potrebbe invece risalire l’albero inviando come input la

stringa ‘/..’ un po’ di volte, arrivando così alla root directory ed inserire poi qualsiasi path (es.:

/../../../../etc/passwd).

Questa tecnica si chiama directory trasversal: l’utente accede ad una parte di file system di cui non ha

accesso.

Input validation: bisogna filtrare tutti gli input che potrebbero essere pericolosi (non bisogna mai fidarsi che

gli input siano quelli che ci si aspetta).

IntegerOverflow

In matematica gli interi sono infiniti (ed in genere anche i programmatori tendono a pensarla così), mentre i

sistemi informatici li rappresentano in binario con un numero finito di bit, quindi il numero di interi

rappresentabili è finito.

Cosa succede quando si va oltre il massimo numero rappresentabile?

 Interi senza segno: il numero successivo è 0

 Interi con segno: il numero successivo è il minore rappresentabile (numero negativo)

Es.: combine: funzione che prende in input due vettori,

questi vengono poi concatenati e salvati nel buffer

creato precedentemente. Prima di far ciò

si controlla che la somma della lunghezza dei vettori sia

minore della dimensione del buffer finale.

Se i due buffer in input fossero tanto grandi in modo tale che la loro somma vada oltre al massimo

rappresentabile, tale numero sarebbe negativo e passerebbe il controllo dell’if, andando così a

scrivere dei dati in un buffer troppo piccolo per contenerli con la conseguenza di scrivere in una zona

di memoria assegnata ad altro (buffer overflow).

Memory allocation: Buffer Overflow

Quando un programma viene eseguito, il sistema operativo predispone una zona di memoria divisa in:

 Stack: contiene i returnaddress, le variabili locali e gli argomenti delle funzioni chiamate. Quando una

funzione termina, l’esecuzione riprende a partire dal returnaddress specificato.

 Heap: memoria allocata dinamicamente

Sia stack che heap crescono dinamicamente.

Buffer overflow: un buffer è una implementazione concreta di una variabile. Se il valore assegnato alla

variabile eccede la dimensione del buffer, le locazioni di memoria successive vengono sovrascritte e cambia

il valore della variabile a cui erano assegnate. Un attaccante potrebbe quindi generare di proposito un

buffer overflow per modificare delle variabili a suo vantaggio.

Linguaggi come il Java sono type-safe e memory-safe, ovvero impediscono che una variabile possa accedere

ad una zona di memoria allocata ad un’altra variabile. Il risultato è però un linguaggio molto lento.

Linguaggi come il C o il C++ lasciano al programmatore il compito di allocare e deallocare la memoria e non

offrono questo tipo di controlli. Hanno però prestazioni maggiori, necessarie per un sistema operativo.

La struttura dello stack è fissa ed è semplice capire in anticipo dove un particolare buffer verrà posizionato

nello stack.

 Return address: una volta che è terminata, si riprende l’esecuzione dall’indirizzo puntato dal

returnaddress (in genere codice eseguibile)

 Stackpoienter: puntatore all’ultimo elemento dello stack

Stack-basedoverflow: durante l’esecuzione di un programma viene chiesto un input dall’utente. La variabile

corrispondente a tale input viene salvata nello stack, al di sotto di altre variabili (altre variabili del

programma, returnaddress e stack pointer). L’attaccante potrebbe inserire volontariamente un input

troppo grande per essere contenuto nel buffer della variabile corrispondente, generando così un buffer

overflow e sovrascrivendo le altre variabili, compresa returnaddress. A questo punto, quando il programma

termina, l’esecuzione riprende dalla locazione di memoria puntata dal returnaddress, che però ora è quella

scritta dall’attaccante.

Es.: L’input viene scritto all’interno di un buffer di 128 posti (ci si aspetta che sia

minore), tuttavia non si fanno controlli sulla sua lunghezza effettiva. Se l’attaccante inviasse un input

maggiore, supererebbe la dimensione del buffer assegnatoli e sovrascriverebbe stack pointer e

returnaddress.

Se la locazione di memoria a cui punta ora returnaddress non esiste, il programma crasha. L’attaccante

vuole però indurre la macchina vittima ad eseguire il suo codice. Per far ciò scrive il programma in

linguaggio macchina (shellcode scritto come sequenze di byte) e lo inserisce come input, così che venga

copiato all’interno dello stack (zona di memoria per i dati, ma nelle architetture Intel è anche eseguibile).

Alla fine aggiunge poi la locazione di memoria dello stack da cui partirà il suo programma in maniera tale

che venga sovrascritta nel returnaddress.

Es. di input: XAB/XCC/XEP/0xbfffff (la prima parte è la sequenza di byte dello shellcode, mentre alla

fine c’è un indirizzo di memoria). In genere il shellcodeaddress viene replicato molteplici volte alla fine

dell’input, così da riempire eventuale spazio rimanente all’interno del buffer.

Se il programma originale in esecuzione avesse i permessi di root, anche lo shellcode dell’attaccante

avrebbe tali permessi e l’attaccante avrebbe il completo controllo della macchina.

Ma come fa l’attaccante a conoscere lo specifico indirizzo a cui saltare? Grazie alla memoria virtuale un

processo usa gli stessi indirizzi sia sulla macchina della vittima che su quella dell’attaccante (sarà poi la

MMU ad occuparsi di tradurli in indirizzi fisici). L’attaccante può dunque fare delle prove in locale sulla sua

macchina per arrivare a scoprire l’indirizzo desiderato.

TypeConfusion

Typesafety: proprietà di un linguaggio di programmazione (come il Java) che assegna un tipo alle variabili e

se queste poi cercano di cambiare tipo senza le dovute chiamate genera errore. Quando un programma

Java referenzia una variabile (o un oggetto) genera un puntatore all’indirizzo di memoria contenente la

variabile.

Typeconfusion: attacco che induce il linguaggio ad avere due puntatori (che dovrebbero puntare ad oggetti

di diverso tipo) alla stessa zona di memoria.

Il linguaggio fa solo un controllo a livello software, pertanto questo tipo di attacchi sono a livello hardware:

magneti, calore, infrarossi, rowhammer (scritture costanti in memoria): per fare typeconfusion basta

cambiare pochi bit che possono essere osservati in maniera deterministica.

SQL Injection

SQL injection: permette di modificare la query al fine di leggere tutte le informazioni presenti all’interno del

database.

Es.: SELECT * FROM client WHERE name=‘$name’

Ci si aspetta che l’utente inserisca il proprio nome. L’attaccante però potrebbe inserire, invece del

nome, la stringa “Bob’ OR 1=1”, in tal modo la query diventerebbe:

SELECT * FROM client WHERE name=‘Bob’ OR 1=1

In questa query la condizione del WHERE è sempre vera (1=1), quindi restituirebbe l’intera tabella

client.

Come contromisura è possibile utilizzare dei sistemi di filtering: controllano che non ci siano caratteri

pericolosi come gli apici.

10.b Difese software

Il buffer overflow è un attacco in memoria basato su 3 principi:

 Possibilità di iniettare codice nello stack

 Conoscenza dell’indirizzo di memoria del buffer dove inizia lo shellcode

 Possibilità di sovrascrivere il returnaddress

Secure Return AddressStack (SRAS)

Il returnaddress della funzione non viene salvato solo all’interno dello stack, ma anche in un altro registro

che si trova in una zona di memoria diversa. Quando la funzione termina, l’hardware rimpiazza il

returnaddress dello stack con quello salvato nel registro separato e subito dopo il programcounter assume

il valore del returnaddress. In questo modo, se l’attaccante lo avesse modificato, verrebbe nuovamente

sostituito con quello originale.

Limiti:

 Esecuzione di applicazioni multithread: non si sa quale thread termini prima, pertanto potrebbe

essere stato salvato nel registro esterno il returnaddress del thread sbagliato. Tuttavia, creare un

registro esterno per ogni thread sarebbe troppo costoso

 Esecuzione di funzioni ricorsive innestate

Stack non eseguibile

Stack non eseguibile (DEP – Data ExecutionPrevention): zona di memoria esclusivamente per i dati che non

può essere eseguita.

Codice polimorfico: ha bisogno di avere delle zone di dati che siano anche eseguibili. È possibile dare a

questo tipo di programmi dei permessi speciali.

Return-to-libc: DEP impedisce all’attaccante di eseguire il codice iniettato nello stack, ma non di modificare

il returnaddress. Pertanto l’attaccante può sostituirlo con l’indirizzo di memoria della routine di libreria di

sistema (LIBC) che gli serve, passando come parametri i valori che inserisce nello stack (non può eseguire,

ma può ancora scrivere).

In risposta a questo nuovo attacco è possibile limitare la libreria, caricando solo le funzioni che servono allo

specifico programma in esecuzione. Se l’attaccante avesse bisogno di una funzione che non serve al

programma, non potrebbe dunque puntare ad essa.

ROP (Return-Oriented Programming): anche se LIBC è limitata solo ad alcune funzioni, queste sono

composte da istruzioni. L’attaccante, invece di puntare all’inizio della funzione come in return-to-libc, può

saltare alla singola istruzione di cui ha bisogno, dopo di che può saltare ad un’altra e così via, fino a

comporre la funzione di cui ha bisogno. Queste funzioni si chiamano istruzioni gadget e terminano sempre

con una ret (serve per andare al returnaddress).

Tipi di architettura:

 RISC (ReducedInstruction Set Computer): architettura semplice e lineare. Es.: Android.

 CISC(Complete Instruction Set Computer): contiene istruzioni in grado di eseguire operazioni

complesse in una singola istruzione. Es.: Intel.

In questo tipo di architettura è possibile non solo saltare all’inizio di un’istruzione, ma anche in mezzo,

avendo così la possibilità di individuare ed utilizzare istruzioni disallineate non presenti nel set iniziale

(viene cambiato il valore semantico dell’istruzione)

Canarini

Canarini: sequenza di 4 byte che viene messa a protezione del returnaddress. Quando viene chiamata una

funzione il compilatore inserisce i suoi parametri all’interno dello stack e posiziona subito sotto al

returnaddress un canarino di valore casuale. Se l’attaccante fa un buffer overflow, per poter sovrascrivere il

returnaddress deve sovrascrivere anche il canarino, ma non ne conosce il valore (poiché è casuale). Quando

la funzione termina, sempre il compilatore controlla che il canarino attuale sia uguale a quello inserito

all’inizio. Solo se i valori corrispondono allora si procede con l’esecuzione.

Per poter utilizzare questa tecnica, il compilatore deve aggiungere due macroistruzioni e deve mantenere

una memoria temporanea dove salvare il canarino. Questa zona di memoria è considerata trusted (TCB).

ASLR (Address Space Layout Randomization)

Gli attacchi buffer overflow e return-to-libc si basano sul fatto di conoscere l’indirizzo virtuale del codice nel

buffer o delle routine della libreria standard. È facile ottenere queste informazioni, poiché spesso si

utilizzano gli stessi indirizzi su molte macchine diverse.

ASLR: tecnica di randomizzazione degli indirizzi per far sì che gli indirizzi dello stack e delle routine di libreria

siano diversi per ciascuna macchina (sposta gli indirizzi di un certo offset).

Attacchi conseguenti a questo tipo di difesa:

 Brute force: si provano in continuazione degli indirizzi random differenti

 Sprayingattack: si riempie la memoria del processo dei pezzi di codice (shellcode) tutti uguali e si

sovrascrive il returnaddress con un valore casuale. Con grande probabilità questo indirizzo

corrisponderà ad una locazione di memoria in cui c’è lo shellcode, che verrà quindi eseguito.

Questo attacco è però piuttosto evidente, poiché genera un picco costante di allocazione di zone di

memoria.

Es. storico: PaX ASLR

Funzioni sicure

C è un linguaggio famoso per avere molte funzioni pericolose. Sarebbe dunque necessario rimpiazzarle con

funzioni che specificano in numero di byte o caratteri.

Es.: strcpy non controlla la dimensione dei buffer, ma può essere sostituita con strncpy.

Filtering

Gran parte degli attacchi software è dovuta al fatto che non viene fatto un giusto controllo degli input a

livello di codice. È possibile filtrare gli input per rendere più difficile inserire input volutamente pericolosi:

 Whitelisting: liste che specificano quali input sono permessi. Funziona bene quando si richiede un

input specifico.

 Blacklisting: liste che specificano quali input respingere (es.: caratteri speciali per l’inserimento di

codice).

 Taintanalysis: quando arriva un input da una sorgente non sicura lo si marchia. Se questo input accede

a qualche funzione critica per la sicurezza viene bloccata l’esecuzione. Il problema di questo tipo di

analisi è che rallenta parecchio il sistema.

Caratteri pericolosi possono essere sanitizzati usando delle codifiche sicure oppure tramite dei caratteri di

escape.

14. Crittografia

Introduzione

Crittografia: scienza che studia la scrittura segreta. In particolare studia tecniche matematiche relative alla

sicurezza delle informazioni (aggiunge confidenzialità ai dati).

Cryptoanalysis: scienza che studia i metodi con cui rompere la crittografia.

 Vecchio paradigma: due enti fidati vogliono comunicare tra di loro attraverso un canale non sicuro,

l’attaccante può leggere, cancellare ed inserire messaggi all’interno del canale. Con la crittografia i

due enti costruiscono un canale sicuro sopra una rete non sicura.

 Nuovo paradigma: i due enti comunicanti non si fidano l’un l’altro. Bisogna proteggere si da una frode

tra i due che da enti esterni alla conversazione. Per far ciò si richiede il controllo di una Trusted Third

Parties (TTP)

 Applicazione della legge: legge che regola come la polizia possa intercettare il traffico decriptato (può

chiedere la chiave crittografica)

Proprietà:

 Data confidentiality: gli algoritmi di cifratura nascondono il contenuto del messaggio

 Data integrity: funzioni che controllano che il messaggio non sia stato modificato

 Data originauthentication: gli algoritmi di firma digitale verificano la sorgente e l’integrità del

messaggio (un messaggio modificato non arriva più dalla sorgente originale)

La crittografia rinchiude i segreti in una cassaforte e per aprirla è necessaria una chiave.

Principio di Kerckhoff: gli algoritmi di cifratura non sono mai segreti, ma lo sono le chiavi (sono le chiavi che

vanno protette).

Shiftingproblem: il problema prima era che le comunicazioni avvenivano su un canale non sicuro, ora invece

i canali sono sicuri, ma è necessario proteggere le chiavi di cifratura.

Tipologie di sistemi crittografici:

 Sistema simmetrico: c’è una chiave unica che deve essere condivisa tra le entità che vogliono

comunicare. È molto veloce, ma c’è il problema di trovare un modo sicuro per scambiare la chiave.

 Sistema a chiave pubblica/privata: più lenta, ma non c’è bisogno di scambiarsi la chiave.

Funzioni di controllo dell’integrità

La crittografia è basata sulle hashfunction: per proteggere un programma x si calcola la hashh(x) e la si salva

dove non può essere modificata. Il calcolo della hash non richiede informazioni segrete.

Es.: quando si effettua il login si invia la password in chiaro. A questa viene applicata la funzione hash e

viene confrontata con il valore contenuto nel file /etc/shadow.

Le funzioni hash sono dette anche funzione one-way:

 Sono facili da calcolare

 Applicano algoritmi di compressione

 Pre-image resistance: dato un valore y, è computazionalmente impossibile trovare una x tale che

h(x)=y

Un attaccante potrebbe però cambiare un programma x in x’ maligno in modo tale che h(x’)=h(x). In questo

caso si dice che c’è una collisione tra gli input x e x’. Pertanto, la protezione dell’integrità necessita di

funzioni hash che siano collision-resistant:

 2nd pre-image resistance (weakcollisionresistance): dato un input x e la sua h(x), è

computazionalmen-te impossibile trovare un altro input x’≠x tale che h(x)=h(x’)

 Collisionresistance (strong collisionresistance): è computazionalmente impossibile trovare due input x

e x’, con x’≠x, tali che h(x)=h(x’)

ManipulationDetection Code (MDC): utilizzati per individuare le modifiche di un documento. Ne esistono di

due tipi:

 One-Way HashFunction (OWHF): facili da calcolare, fanno compressione, pre-image resistance e 2nd

pre-image resistance

 CollisionResistantHashFunction (CRHF): facili da calcolare, fanno compressione, 2nd pre-image

resistance e collisionresistance

Il core di una funzione hash è la funzione di compressione f che funziona su input di dimensione fissa. Un

input x di lunghezza arbitraria viene suddiviso nei blocchi 



, …, 



della dimensione degli input di f

(l’ultimo blocco deve essere riempito con dei bit cuscinetto). A questo punto si applica la funzione di

compressione: sia 



un valore iniziale fissato, si calcola 



 











per i=1, …, m(il simbolo || sta per

concatena-zione).



sarà infine il valore hash di x.

Message Authentication Code (MAC): famiglia di funzioni 



 che vengonocalcolate dati due input: il

messaggio x e la chiave k(funzione hsah autenticata). Per verificare il messaggio, la chiave deve essere

condivisa tra mittente e destinatario. Un MAC deve inoltre avere le seguenti proprietà:

 Facile da calcolare

 Compressione

 Computatonresistance: per ogni valore di k, data una o più coppie 











, è

computazionalmente impossibile calcolare 



 per ogni nuovo input x.

Un algoritmo MAC può essere derivato da un algoritmo MDC h usando il costrutto HMAC: per ogni chiave k

e per ogni messaggio x, si calcola 







 



































 dove 



e 



sono stringhe di bit

(padding) che estendono k per farla arrivare alla dimensione di un blocco nella funzione di compressione f.

Firma digitale

I meccanismi di firma digitale hanno 3 componenti:

 Generazione delle chiavi

 Procedura di firma (privata)

 Procedura di verifica (pubblica)

L’utente A utilizza la chiave privata per firmare il documento m e fornisce la chiave pubblica all’utente B

perché B possa controllare la firma sul documento m che ha ricevuto. Chiunque abbia la chiave pubblica

può verificare che il messaggio sia inviato da colui che possiede la chiave privata.

Entrambi gli enti possiedono la chiave pubblica di tutti e due, inoltre ognuno possiede la sua chiave privata.

A invia a B il documento M firmato con la sua chiave privata, quindi 



 e B può verificarlo con la chiave

pubblica di A: 

















 .

Man In The Middle (MITM): un attaccante potrebbe intercettare l’invio della chiave pubblica di A,

sostituen-dola con la sua (



), e fare lo stesso con la chiave pubblica di B. Ora sia A che B hanno la chiave

pubblica dell’attaccante, ma pensano di avere quella l’uno dell’altro. Pertanto, se A invia un documento

firmato a B, in realtà lo invia all’attaccante, che può sostituirlo con il suo, firmarlo con la sua chiave ed

inviarlo a B, che penserà di averlo ricevuto da A.

Per risolvere questo problema si utilizzano dei certificati digitali, i quali contengono le chiavi pubbliche dei

due interlocutori e sono firmati da una trusted authority.

RSA (Rivest, Shamir, Adleman): algoritmo di generazione delle chiavi basato sulla scelta di due numeri

primip e qmolto grandi e distanti tra loro. Le chiavi sono:

 Chiave privata: un intero d tale che mcd(d, p-1)=1 e mcd(d, q-1)=1

 Chiave pubblica: un intero n=p∙q ed un esponente e tale che e∙d=1 modmcm(p-1, q-1)

MAC e firma digitale sono meccanismi di autenticazione.

Cifratura

Cifratura: protezione della confidenzialità dei dati.

 Cifratura: un testo in chiaro x viene convertito in un testo cifrato attraverso una chiave K

 Decifratura: utilizzando la chiave K è possibile ricavare il testo in chiaro da quello cifrato y

Si distingue in due tipi di cifratura:

 Cifratura simmetrica: la chiave è la stessa per cifratura e decifratura

 Cifratura asimmetrica: le chiavi sono diverse ed è computazionalmente impossibile ricavare la chiave

privata di decifratura dalla corrispondente chiave pubblica di cifratura

La cifratura simmetrica è più efficiente, ma ha il problema di dover scambiare la chiave. Essendo la chiave

un valore molto piccolo rispetto a tutto il documento allora è possibile scambiare solo quella con una

cifratura asimmetrica senza perdere troppo in performance.

A e B devono condividere la loro chiave condivisa K per potersi inviare messaggi cifrati. A invia quindi la

chiave utilizzando la chiave pubblica di B (



) e B potrà decifrare il messaggio utilizzando la sua chiave

privata: 

















 .L’attaccante non può decifrare il messaggio (non conosce K), ma può sostituire il

messaggio contenente la chiave condivisa con la sua chiave 



, inviando 







 (conosce la chiave

pubblica di B). Per evitare ciò è necessario che A firmi il messaggio con la sua chiave privata: 













. In

questo modo A certifica di essere A ed il messaggio può essere letto solamente da B.

Diffie e Hellman: schema che permette di scambiare la stessa chiave simmetrica senza usare chiave

pubblica e privata.

Due tipi di algoritmi:

 A blocchi (block): vengono cifrate delle sequenze di blocchi di dati piuttosto grandi senza cambiare la

chiave. La sicurezza si concentra sul design di funzioni di cifratura.

 A flusso (stream): vengono cifrate delle sequenze di blocchi piccoli dopo di che si cambia chiave. La

sicurezza di concentra sul design del generatore di chiavi, anche se la cifratura è piuttosto semplice.

Problema delle chiavi asimmetriche: come si fa ad ottenere la chiave pubblica dell’ente a cui voglio

mandare un messaggio? Esistono dei server appositi per la verifica e l’autenticazione delle chiavi (Public

KeyInfrastructure - PKI).

17. Network Security

Botnet: aggregato di macchine compromesse collegate con una sottorete e controllate da un attaccante.

Un attaccante può fare le seguenti azioni:

 Leggere messaggi

 Applicare tecniche di spoofing (falsificazione dell’identità)

 Tentare di indovinare i campi di un messaggio che non può vedere

Attacchi TCP

TCP three way handshake:

1. Il mittente invia un flag SYN ed un valore casuale x(numero di sequenza del mittente)

2. Il destinatario risponde anche lui con un SYN ed un ACK più i valori x+1 (per indicare che il prossimo

segmento che si aspetta di ricevere) e y (numero di sequenza del destinatario)

3. Il mittente risponde con un ACK, y+1 (prossimo segmento che si aspetta) e x+1 (numero di sequenza

del nuovo segmento)

TCP Session Hijacking

1. L’attaccante inizia la connessione cambiando il suo indirizzo sorgente (spoofing) con uno trusted dal

computer vittima (poiché sta nella sua stessa sottorete, quindi non ne richiede l’autenticazione), invia

quindi un segmento TCP con flag SYN alzato ed un valore x

2. La vittima riceve il messaggio ed invia la risposta non all’attaccante, ma al computer cui l’attaccante

ha rubato l’identità

3. Nonostante l’attaccante non veda la risposta, può provare lo stesso ad indovinare il valore y (ha dietro

delle regole che lo rendono meno casuale di quanto dovrebbe) ed invia il terzo messaggio di

connessione con questo valore

Se il valore di y è stato indovinato, la vittima pensa di aver iniziato una connessione sicura con un host

fidato quando in realtà sta comunicando con l’attaccante. L’attaccante non può ricevere messaggi (vengono

inviati al vero computer fidato), ma può comunque inviare comandi alla vittima con i privilegi del computer

a cui ha rubato l’identità.

TCP SYN Fload

L’attaccante invia un messaggio di sincronizzazione alla vittima, sempre con un indirizzo non suo tramite

spoofing. Quando alla vittima arriva il messaggio, questa crea una struttura di memoria dove mantiene i

numeri di sequenza x e y (più altre informazioni), dopo di che invia la risposta. L’attaccante continua quindi

a mandare sempre il messaggio di sincronizzazione, cambiando il numero di sequenza, e la vittima continua

ad allocare zone di memoria finché non la satura e non è più in grado di iniziare una conversazione (denial

of service).

In C non esistono funzioni per fare solo la SYN iniziale, ma fanno direttamente tutte e 3 le connessioni.

SYN cookie: la memoria con le informazioni necessarie viene allocata solo dopo al three way handshake,

quando la macchina sa di star comunicando con qualcuno di reale. Tuttavia c’è bisogno di quelle

informazioni anche prima, allora vengono mando cifrate in piggybacking e, se arrivano all’interlocutore

reale, verranno rimandate indietro sul terzo messaggio e il computer sarà in grado di decifrarle (poiché

conosce la chiave, visto che l’ha creata lui).

Attacchi DNS

DNS: servizio essenziale per il funzionamento di Internet, poiché permette di risolvere i nomi in indirizzi IP e

vice versa.

L’infrastruttura DNS comprende:

 13 root server: contengono al loro interno tutti i nomi dei top level domain server

 Global Top Level Domain (GLDT) server: corrispondono ai domini di primo livello (es.: .com, .net, …)

 Authoritativename server: mappano gli hostname e gli indirizzi IP della loro zona

 Recursive name server: primi server che vengono contattati dai client quando questi devono risolvere

un indirizzo

Ogni name server mantiene una cache ed ogni volta che gli viene fatta una richiesta controlla prima nella

cache se già possiede la risposta. Le risposte rimangono nella cache per un tempo definito dal campo time-

to-live (TTL) definito dal mittente.

Ogni volta che si fa una richiesta viene generato un QID (numero di sequenza) in modo tale da potervi

associare una risposta. Se il QID della risposta che arriva non corrisponde a nessuno dei QID delle domande

inviate, la risposta viene scartata.

Un attaccante potrebbe voler sostituire il suo indirizzo IP con quello di un nome simbolico molto usato, così

che gli utenti si connettano al suo sito invece di quello richiesto (l’utente si fida del sito ritornato dal DNS).

Ciò rende il DNS un protocollo tanto sensibile quanto pericoloso.

Debolezze del protocollo:

 L’unica autenticazione che si ha delle risposte che si ricevono è data dal QID. Se l’attaccante riuscisse

ad indovinarlo potrebbe inviare come risposta ad una richiesta di risoluzione di un nome il proprio

indirizzo IP prima che arrivi la risposta del server autoritativo. Il name server, vedendo che il QID è lo

stesso della sua richiesta, inoltra la risposta al client.

 Cache poisoning: se l’attaccante riuscisse ad inviare il suo indirizzo ed a farlo accettare dal name

server, questo verrebbe salvato all’interno della cache e vi rimarrebbe fino allo scadere del TTL. In

questo tempo accadrebbe che chiunque cerchi di connettersi al dominio il cui valore è stato falsificato

nella cache si connetterebbe in realtà al sito dell’attaccante.

È importante generare dei QID che siano il meno possibile predicibili.

L’attaccante potrebbe inoltre cercare di rallentare il server autoritativo generando un DoS, in mondo tale

da aumentare le probabilità che la sua risposta arrivi prima di quella autentica.

Dan Kaminski’s Attack

L’attaccante invia al recursive server una richiesta per l’indirizzo ‘random.foo.com’. Questo è un indirizzo

inesistente, poiché non si vuole che sia già presente nella cache, quindi il recursive server deve inoltrare la

richiesta agli altri server. Ora l’attaccante vuole inviare la risposta prima dei server autoritativi, ma non

conosce il QID, pertanto continua ad inviare messaggi provando con tanti QID diversi e, se riesce a trovare

quello giusto prima che arrivi la risposta reale, il suo indirizzo viene salvato all’interno della cache del

recursive server.

Tuttavia nessuno andrà mai a cercare l’indirizzo random.

Ogni volta che viene inviata una risposta si mandano anche altre informazioni, tra cui l’indirizzo del server

di riferimento (serve per velocizzare la ricerca nel caso si presenti una nuova richiesta per un determinato

dominio, in questo modo si evitano tutte le richieste ai server intermedi). Ciò che fa l’attaccante è, quindi,

inviare insieme alla risposta l’indirizzo del server DNS salvato sul suo computer. In questo modo, tutte le

richieste che verranno fatte per il dominio ‘foo.com’ saranno in realtà inoltrare al server DNS

dell’attaccante.

Contromisure:

 Fare le varie richieste su varie porte, in questo modo l’attaccante non solo deve indovinare il QID, ma

anche il numero di porta

 Restringere l’accesso ai local recursive name server

 Eseguire controlli d’accesso per prevenire la sovrascrittura non autorizzata di dati autoritativi

 DNSSec: autenticazione crittografica attraverso firma digitale

DNS Rebinding Attack

Sameorigin policy (proprietà di sicurezza): uno script web può essere collegato solo al server da cui è stato

scaricato.

L’attaccate crea un nuovo dominio (es.: attacker.org). Per far ciò deve fare una richiesta ad un’autorità e,

una volta accettata, il dominio viene automaticamente aggiunto ai DNS. Tra le varie opzioni è possibile

associare al dominio diversi indirizzi IP ed assegnare loro un time-to-live, scaduto il quale l’indirizzo IP

cambia. Gli indirizzi che l’attaccante associa al suo dominio (con TTL breve) sono il suo e quello del suo

target. Quando la vittima visita la pagina, scarica anche uno script malevolo che attende la scadenza del TTL

prima fare di connettersi ad attacker.org. Scaduto il TTL, il dominio non è più connesso al computer

dell’attaccante, ma a quello della vittima, pertanto lo script può essere eseguito dato che non infrange la

sameorigin policy.

Firewall

Sistema di prevenzione: filtra il traffico che può entrare nel sistema (filtro in ingresso) e quello che può

uscire dal sistema (filtro in uscita). Le decisioni di controllo degli accessi sono basate su informazioni come

l’indirizzo ed il numero di porta.

In genere, il firewall viene installato tra la rete di un’organizzazione ed Internet, in questo modo tutto il

traffico da e per la rete privata deve passare attraverso il firewall.

Tipi di firewall:

 Packetfilter: controlla gli header dei pacchetti IP ed il numero di porta di TCP ed UDP e decide,

secondo delle regole specifiche, quali pacchetti lasciar passare e quali no. Le regole controllano il

traffico in entrambe le direzioni.

 Statefulpacketfilter: packetfilter che capisce richieste e risposte (es. in TCP: SYN, SYN-ACK, ACK). Le

regole specificano solo i pacchetti in una direzione, dopo di che le risposte vengono processate

automaticamente.

Politiche di firewall (una politica di firewall è un insieme di regole):

 Permissivi: di default permettono ai pacchetti di entrare, le regole specificano chi deve essere

bloccato

 Restrittivi: di default bloccano i pacchetti, le regole definiscono chi può passare (più sicuro)

Un firewall può bloccare solo il traffico che passa attraverso esso, pertanto deve essere posizionato in

maniera attenta.

Es.: dove posizionare il mail server? Bisogna controllare le mail che arrivano dall’esterno, quindi deve

essere all’interno della zona protetta. Bisogna però controllare anche ciò che arriva dalla rete, quindi deve

trovarsi anche all’esterno.

Soluzione: DMZ (perimeter network) contenete i server, in modo tale da controllare il flusso sia in ingresso

che in uscita attraverso due firewall.

Limiti dei firewall:

 I firewall non proteggono dai problemi interni alla rete

 Bloccare i servizi potrebbe creare problemi per gli utenti

 Alcuni protocolli sono più difficili da supportare

 Protocoltunnelling: inviare dati di un protocollo attraverso un altro protocollo per evitare i firewall

(es.: la porta 80 viene spesso lasciata aperta, quindi molti protocolli fanno tunnelling attraverso http)

 Non è possibile esaminare e filtrare il traffico criptato

IntrusionDetectionSystem (IDS)

Due principali approcci per fare detection:

 Knowledge-based (misusedetection): hanno un database di pattern che indicano un comportamento

sospettoso che potrebbe indicare pericoli (es.: un numero molto alto di tentativi di login falliti su un

host sensibile).

Questo tipo di sistema non è però in grado di individuare nuove tipologie di attacco, poiché non

presenti nel database. Tali dovrebbero quindi essere costantemente aggiornati, diventando talmente

grandi da rendere lento il sistema IDS.

 Behaviour-based (anomalydetection): cercano di stabilire quale sia il comportamento normale del

sistema, collezionano poi dei dati statistici per capire quanto il sistema si distacchi dal

comportamento base. Quando una determinata soglia viene superata, allora genera un allarme.

È possibile che vengano generati dei falsi positivi (si riscontrano degli attacchi quando in realtà non ce

ne sono) o dei falsi negativi (non vengono individuati degli attacchi perché il loro effetto viene

percepito come comportamento normale).

Architettura IDS: set di sensori distribuito in modo da ottenere dati connessi ad una console centrale che

gestisce i sensori, analizza i dati e riporta le anomalie. Bisogna proteggere tutta l’infrastruttura, altrimenti

un attaccante potrebbe manipolarla per non far rivelare un suo possibile attacco.

Tipi di IDS:

 Network-based IDS (NIDS): controllano eventuali attacchi nel traffico di rete (analisi in tempo reale)

 Host-based IDS (HIDS): controllano eventuali attacchi nei file di log degli host

Esistono degli attacchi che possono essere individuati dai NIDS ma non dagli HIDS (es.: SYN flood) e vice

versa (es.: Trojan login script). L’ideale sarebbe quindi combinare i due tipi di IDS.

Honeypot

Per scoprire nuovi attacchi è possibile mettere online dei sistemi appositi che fanno finta di essere dei

sistemi contenenti dati sensibili al fine di attirare gli attaccanti, ma in realtà tali dati sono falsi. Questi

sistemi vengono tenuti sotto controllo per vedere se qualcuno cerca di attaccarli in qualche modo.

Honeypot: tecnologia per tracciare, apprendere e raccogliere informazioni sulle attività degli hacker.

Livelli di coinvolgimento:

 Low interaction: monitorano semplicemente le porte

 Midinteraction: programmi che emulano sistemi operativi e servizi

 High interaction: veri e propri computer, applicazioni o servizi

Al crescere del livello di interazione cresce anche la qualità delle informazioni che si possono ottenere, ma

sono sistemi più complessi da realizzare.

Honeynet: rete di honeypot.

Honeywall: honeynet comprensiva anche di firewall e IDS

16. Communications Security

Threat model

L’attaccante ha accesso al canale di comunicazione tra due end point: può sia vedere che modificare i

messaggi.

Un attaccante può essere:

 Passivo: ascolta solamente il traffico.

- Sniffing: l’attaccante è interessato al contenuto del messaggio

- Trafficanalysis: il traffico viene analizzato al fine di identificare dei pattern di comunicazione

 Attivo: interviene modificando i messaggi o inserendo nuovi messaggi

- Spoofing: l’attaccante falsifica l’indirizzo del mittente

- Flooding: vengono inviati moltissimi messaggi alla vittima

- Squatting: l’attaccante finge di trovarsi nella posizione della vittima

Securetunnels

Secure tunnel: connessione logica sicura tra due end point all’interno di una rete non sicura.

I tunnel sicuri sono costruiti nel seguente modo: un protocollo stabilisce un segreto tra le due entità e

successivamente vengono derivate delle chiavi simmetriche dal segreto condiviso. Tutto il traffico

successivo sarà protetto da queste chiavi.

Vengono utilizzati algoritmi asimmetrici costosi solo per lo scambio della chiave, dopo di che la

comunicazione vera e propria viene fatta con algoritmi simmetrici (che usano la chiave scambiata in

precedenza) in maniera tale da essere più veloce.

Replyattack: l’attaccante può osservare i pacchetti ma non può cambiarne il contenuto (integrità), allora li

salva sulla propria macchina per poi reinviarli. Per evitare questo tipo di attacco si utilizzano i nonces,

ovvero dei numeri casuali che permetto di identificare se un messaggio è vecchio oppure nuovo.

IPsec

IPsec è uno standard che fornisce sicurezza a livello rete (non è necessario riscrivere o modificare le

applicazioni). È opzionale per IPv4, ma obbligatorio per IPv6.

Ha due modi di funzionamento:

 Transport mode: gli host sono consapevoli di comunicare con IPsec (sicurezza host-to-host). L’host

che genera il messaggio aggiunge direttamente l’header di IPsec e l’host destinatario sa interpretarlo.

 Tunnel mode: gli host non sanno di star comunicando con IPsec. Il mittente crea un pacchetto IP

normale e lo invia. Questo arriva poi al gateway, il quale si occupa di cifrare l’intero pacchetto e di

metterlo come payload di un pacchetto IPsec (incapsulamento), dopo di che lo invia nella rete. La

comunicazione tra host e gateway resta però in chiaro.

Ci sono due modalità in cui il pacchetto può essere costruito:

 AH (AuthenticationHeader): protocollo più vecchio, non viene quasi più utilizzato.

- Data integrity

- Data originauthentication

- Previene lo spoofing degli indirizzi IP (indirizzi IP autenticati)

- Crea un canale statefull usando numeri di sequenza (numeri di sequenza autenticati)

 ESP (Encapsulation Security Payload): protocollo più giovane.

- Payloadconfidentiality

- Data originauthentication

- Data integrity

- Payloadauthentication

- Cifratura simmetrica basata su chiavi condivise dagli end point

ESP

Quando si utilizza ESP vengono aggiunti al datagramma IP un header ed un tailer specifici:

 Header:

- SPI (Security Parameter Index): identifica quale algoritmo e quale chiave si devono utilizzare

- Numero di sequenza

 Tailer:

- Padding necessario all’algoritmo di cifratura

- Lunghezza del padding

- Dati di autenticazione: serve per poter fare un check di integrità

ESP può essere utilizzato in due modi:

 In transport mode (host-to-host): in genere il pacchetto di un protocollo di livello superiore (es.: TCP o

UDP) viene incapsulato all’interno di un pacchetto IP per essere inviato. In transport mode l’host è

consapevole di star utilizzando IPsec, quindi costruisce il pacchetto in maniera differente. Il pacchetto

di livello superiore viene incapsulato all’interno di ESP, dopo di che viene aggiunto in testo lo header

IP originale.

 In tunnel mode:l’host invia il pacchetto IP standard. Il gateway incapsula l’intero pacchetto all’interno

di ESP ed aggiunge poi in testo lo header IP esterno (viene ulteriormente incapsulato in un pacchetto

IP)

MAC scope: l’attaccante non può cambiare i dati (autenticazione).

Encryption scope: l’attaccante non può vedere il contenuto (cifratura).

IPsec Security Association (SA): associazione unidirezionale tra mittente e destinatario.Al fine di tener

traccia di tutte le SA attive, si utilizza un apposito database, chiamato SAD (Security Association Database),

che mantiene, per ciascuna SA, le seguenti informazioni:

 Gli indirizzi IP dei peer coinvolti nella comunicazione

 Il protocollo che verrà utilizzato per il tunnel (AH o ESP)

 L’algoritmo di cifratura e la chiave

 L’SPI (Security Parameter Index), che viene inserito nello header ESP

Più SA possono essere combinate tra loro, ad esempio, in caso si debbano innestare multipli livelli di tunnel

IPsec. Ogni tunnel può iniziare/finire in un gratewayIPsec diverso lungo la rotta.

Es.: due host remoti hanno accesso ad un gateway. Il traffico dall’host al server viene protetto da un tunner

interno. Il traffico su Internet viene protetto da un tunnel esterno.

IKE

IKE (Internet Key Exchange): protocollo per lo scambio di chiavi su Internet. Viene utilizzato da IPsec per

scambiare, tra i due host, un segreto dai quale poi è possibile derivare la chiave necessaria per instaurare

un canale sicuro tramite SA.

DoS (Denial-of-Service): l’attaccante manda un messaggio finto alla vittima, la quale fa operazioni di

crittografia molto costose (es.: controllo della firma digitale). Gli attacchi DoS non possono essere evitati,

ma è possibile mitigarne gli effetti creando dei protocolli tali per cui il costo delle operazioni che fa

l’attaccate sia comparabile con il costo delle operazioni della vittima.

DoS su IKE(contro chi inizia la conversazione): il mittente invia un IKE_SA_INIT per iniziare ad accordarsi sul

segreto, l’attaccante risponde allora con un messaggio finto. La vittima, ricevendo il messaggio

dell’attaccante, creerà una la SA e la chiave che ne ricava, che tuttavia non saranno utilizzabili ed IKE fallirà.

Contromisura: l’iniziatore accetta molteplici risposte al suo primo messaggio e, all’arrivo di una risposta

valida, scarta tutte le altre.

DoS su IKE (contro il destinatario della conversazione): alla richiesta di apertura di una sessione la macchina

crea una struttura di memoria iniziale dove salvare i dati che le servono. Se l’attaccante continua ad inviare

richieste finte (flooding), prima o poi la memoria del destinatario si satura.

Contromisura: utilizzare un meccanismo stateless attraverso l’utilizzo di cookie.

Il protocollo IKE utilizza UDP.

Security Policy

È possibile definire delle regole di filtraggio dei pacchetti (es.: un host consapevole di IPsec deve sapere

quando scartare un determinato pacchetto). Tali regole sono salvate all’interno di un Security Policy

Database (SPD). Ogni volta che arriva un pacchetto, i suoi campi vengono confrontati con le entry del SPD

per vedere se coincidono ed in tal caso viene identificata una Security Association (SA).

NAT

NAT (Network AddressTranslation): sistema per mascherare più indirizzi privati su un unico indirizzo

pubblico.

NAT dovrebbe essere trasparente a tutte le applicazioni, ma in realtà non è così:

 AH è incompatibile con NAT, poiché fa autenticazione sull’indirizzo IP.

 Il calcolo del checksum di TCP include l’indirizzo IP contenuto nello pseudo header, ma NAT lo

modifica, rendendo invalida la verifica del checksum. Si utilizza allora il NAT Trasversal (NAT-T):

aggiunge un header UDP che incapsula lo header ESP.

SSL/TLS

SSL (SecureSocketLayer) e TLS (TransportLayer Security) sono protocolli largamente utilizzati nel web per

supportare l’e-commerce sicuro su http (HTTPs).

Le applicazioni devono essere consapevoli di star usando SSL (cifratura end-to-end).

Architettura a due livelli:

 SSL handshakeprotocol: promette ai due enti di autenticarsi a vicenda e di negoziare un algoritmo di

cifratura ed un segreto condiviso (dal quale poi verranno ricavate le chiavi)

 SSL record protocol: utilizzato per incapsulare i dati provenienti dai livelli superiori (comunicazione

vera e propria)

Sessione: creata dal protocollo handshake, definisce il set di parametri crittografici (cifratura, funzione

hash, segreto master e certificati). Al suo interno possono esserci più connessioni per questioni di

efficienza.

Connessione: definita dai nonces. Le chiavi vengono derivate da un singolo segreto master creato durante

la fase di handshake (si utilizza una chiave diversa per ogni connessione).

Handshakeprotocol:

1. Il client invia ‘hello’: inizia la connessione.Invia la sua versione del protocollo, il client nonce (numero

random) e propone una lista di suite di cifratura per la generazione delle chiavi

2. Il server risponde al saluto ed invia il certificato firmato da un’autorità (comprensivo della catena di

certificati che validano quello in uso).Invia inoltre la sua versione del protocollo, il server nonce e la

suite di cifratura scelta tra quelle proposte dal client. Finito di inviare tutto avvisa di aver concluso con

la fase di ‘hello’.

3. Il client invia il segreto master utilizzando la chiave pubblica del server (che ha ottenuto dal certificato

del server) ed indica di star cambiando la suite di cifratura che utilizzerà in questa sessione. Alla fine

dichiara di aver terminato.

4. Il server utilizza il segreto master per ricavare la chiave simmetrica (solo lui possiede la chiave privata

per decifrarlo), indica anche lui di star cambiando cifratura e manda il messaggio di fine.

Il client non si autentica mai: non interessa poiché è il client a chiedere i servizi del server e quindi è lui che

deve essere sicuro di starsi connettendo al server giusto.

Applicazioni di SSL: e-commerce sicuro. SSL permette di utilizzare un canale sicuro per inviare le

informazioni della propria carta di credito. L’autenticazione del client viene fatta quando inserisce il pin

della carta di credito.

Attacchi:

 Flame: malware che crea certificati basati sulla collision

 Hearthbleed: buffer overflow in cui l’attaccante riesce a prendere la zona di memoria del browser

contenente le chiavi

EAP

EAP (ExtensibleAuthenticationProtocol): definisce protocolli di autenticazione al livello di flussi di messaggi

astratti chiamati metodi. I metodi possono essere implementati utilizzando una varietà di meccanismi

sottostanti.

Le applicazioni ed il protocollo di autenticazione vedono solo un flusso astratto di messaggi. Pertanto il

meccanismo di autenticazione può essere scelto indipendentemente dall’applicazione e può essere

cambiato senza necessità di riscrivere l’applicazione.

Flusso di messaggi generico:

I messaggi EAP generici scambiano le identità ed incapsulano messaggi di protocolli di autenticazione.

Questi protocolli sono detti metodi e provvedono almeno all’autenticazione in un verso.

EAP Tunnelled TLS (EAP-TTLS): un client si connette ad un server certificato utilizzando TLSper stabilire un

tunnel sicuro. Gli utenti si autenticano attraverso una password.

Algoritmo asimmetrico basato sulle chiavi del server

per verificare l’identità del server e creare il tunnel di

cifratura simmetrica

Verifica dell’identità del client attraverso l’invio della

password all’interno del tunnel

18. Web Security

Introduzione

Due vettori di attacco principali:

 E-mail

 Browser

Web 1.0

Web 1.0: nasce per condividere elementi (pagine statiche) in rete attraverso i link.

 Il browser invia una richiesta HTTP al server.

 Il server riceve la richiesta, ricerca la risposta all’interno di un sistema back-end ed infine restituisce la

pagina HTML al client.

HTTP è un protocollo di trasposto (a livello applicazione) che possiede due metodi principali per eseguire

una richiesta:

 GET: richiede una risorsa al web server. Una risorsa è identificata da una URI (Uniform Resource

Identifier) che è il percorso di tale risorsa all’interno del server. Alla fine della URI può esserci anche

una query contenente alcuni dati.

Es.:

 POST: richiede una risorsa attraverso una URI ed invia contemporaneamente dei dati (pensato per

mandarne di più rispetto ad una query GET).

Attacco: l’attaccante crea un hostname contenente un carattere che somiglia ad uno slash. Un utente che

invia al browser la stringa pensa che l’hostname sia quello che precede il falso slash, ma in realtà non è così

e si collega al sito dell’attaccante invece di quello che voleva veramente.

Difesa: è possibile bloccare caratteri pericolosi oppure mostrare all’utente in che punto il browser divide

l’hostname dalla URI.

Le risposte che il server invia al client sono delle pagine HTML (ovvero delle pagine web) e vengono

mandate attraverso HTTP. Spesso alle pagine HTML sono associati dei fogli di stile in CSS che danno

informazioni su come visualizzare la pagina. Nelle versioni successive del web si è aggiunta la possibilità di

inviare, insieme alla pagina HTML, anche degli script in JavaScript o in altri linguaggi di scripting lato client.

Tali non hanno la facoltà di agire su tutto il sistema, pertanto sono eseguiti all’interno di sandbox.

DOM (Document Object Model): rappresentazione della pagina web utilizzata dai browser (necessaria per il

JavaScript). È una struttura di memoria che salva al suo interno tutte le informazioni relative alla pagina

attuale (es.: document.body contiene tutto l’HTML della pagina, document.URL salva l’URL della pagina e

così via).

Thread model

L’attaccante può vedere solo i messaggi che gli arrivano ed i dati ottenuti da end system compromessi

acceduti attraverso il browser. L’attaccante potrebbe anche cercare di indovinare dei campi predicibili

all’interno di un messaggio che non può vedere.

Sessioni

Con l’avvento dell’e-commerce si è reso necessario mantenere lo stato di una sessione di lavoro. È possibile

fare delle sessioni autenticate grazie a TLS.

La prima volta che un client si connette ad un server, quest’ultimo genera un cookie (numero random

identificativo della sessione di un utente - SID), lo salva in un suo database e lo invia al client insieme alla

risposta. Quando il client lo riceve, lo salva nel browser. La prossima volta che accede al sito, invia con la

richiesta il cookie che aveva salvato, il server lo confronta con quelli contenuti nel suo database e, se trova

un match, ripristina la sessione (sa che conosce il client). I cookie vengono salvati anche nel DOM:

document.cookie.

I cookie possono essere utilizzati per identificare gli utenti, così che non sia necessario richiedere loro

username e password per autenticarsi ad ogni connessione.

Cookie poisoning: se l’attaccante riuscisse a prendere il cookie di un altro utente, allora sarebbe in grado di

connettersi al sito come tale utente senza bisogno di conoscere username e password. Un attaccante

potrebbe cercare di indovinare un cookie, oppure rubarlo dal client o dal server. È quindi necessario far sì

che i coockie non siano predicibili e che vengano salvati in posti sicuri.

Man-in-the-middle attack: in uno scenario EAP-TTLS all’inizio si crea una sessione in cui il server si autentica

al client, dopo di che si crea un tunnel per far sì che anche il client si autentichi al server. L’attaccante

potrebbe però ingannare il client, inducendolo a creare una sessione TLS con lui invece che con il server.

L’attaccante crea poi anche lui una connessione TLS, ma verso il server. Il server invia all’attaccante la

richiesta delle credenziali dell’utente, che viene poi inoltrata al client. Questo risponderà con le sue

credenziali, ma non al server, bensì all’attaccante che le userà per autenticarsi al server e riceverà come

risposta il cookie. L’attaccante può ora impersonificare l’utente.

Difesa: il server può controllare se le credenziali sono state inviate nella stessa sessione in cui lui è stato

identificato dall’utente. Se è così allora sa di star comunicando con lo stesso end system, altrimenti

potrebbe essere in atto un attacco. L’attaccante potrebbe però intercettare anche la prima connessione,

così risulterebbe sempre lo stesso autore dei messaggi.

In risposta a questo nuovo attacco sono state cambiate le specifiche di TLS per la negoziazione della

sessione: tutte le sessioni sono connesse tra loro tramite crittografia.

SameOrigin Policy

Sameorigin policy: tutti gli script che vengono ricevuti da un determinato sito si possono collegare solo a

quel determinato sito. Uno script può quindi accedere solo ad un determinato dominio e non può, ad

esempio, richiedere i cookie di altri.

Due pagine hanno la stessa origine se condividono il protocollo, il dominio ed il numero di porta.

La sameorigin policy può però essere troppo restrittiva in determinati casi, quindi vengono concesse delle

eccezioni.

Parent Domain Traversal (PDT): i nomi di dominio possono essere accorciati eliminando la prima parte (es.:

www.my.orgpuò essere accorciato a my.org). Questo potrebbe essere un problema per determinati

domini, pertanto vengono salvate delle eccezioni all’interno del browser e vengono controllate nel

momento di esecuzione dello script.

Cross Site Scripting (XSS)

Obiettivo dell’attaccante: rubare il cookie di un utente. L’attaccante inserisce uno script malevolo

all’interno di una pagina che il server invia alla vittima (non viola la sameorigin policy), così che il browser lo

esegua e possa recuperare i cookie da inviare poi all’attaccante.

Due diversi tipi di cross site scripting:

 Reflected XSS: l’attaccante deve indurre la vittima a clickare sul suo link

 Stored XSS (+ variante): non c’è più necessità di inviare il link alla vittima

ReflectedXSS

1. L’attaccante induce la vittima a clickare sul suo link attraverso tecniche di phishing: invia una mail

fingendosi il sito e componendo il link in maniera particolare (il link contiene dello script).

Es.: www.banca.it/risorsa<script> JS… </script>

2. La vittima clicka sul link. Il browser fa una richiesta al server per quella determinata risorsa.

Es.: GET risorsa <script> JS… </script>)

3. Il server non trova la risorsa (non esiste) e ritorna al client una pagina HTML d’errore dove specifica a

quale richiesta non ha saputo rispondere (invia quindi anche il nome della risorsa contenente lo

script).

4. Il browser riceve la pagina e vede che c’è del JavaScript, quindi lo esegue. Tale script era stato

preparato dall’attaccante appositamente per recuperare il cookie (dal DOM: document.cookie).

5. Lo script, dopo aver rubato il cookie, fa una connessione verso il computer dell’attaccante e glie lo

invia.

StoredXSS

I dati che vengono prodotti dagli utenti vengono conservati all’interno del server (in database, file system,

…) per poter poi essere mostrati a video (es.: un sito di messaggistica deve salvare il messaggio inviato da A

per farlo vedere a B).

1. L’attaccante scrive un messaggio da pubblicare su un sito e lo struttura in maniera tale che contenga

uno script (dello stesso tipo dell’attacco precedente).

Es.: Ciao! <script> JS… </script>

2. Il server riceve l’input dell’attaccante e lo salva nel suo database.

3. Quando un utente richiede la pagina in cui è stato pubblicato il messaggio dell’attaccante riceve

anche lo script che viene eseguito dal browser. Tale script accede al cookie e lo invia all’attaccante.

Per evitare questo attacco sarebbe necessario filtrare gli input, bloccando tutti quelli contenenti script.

Sono nati però di conseguenza degli attacchi al parsing: si scrivono script in moltissimi modi ed in maniera

tale da nasconderlo. In questo modo non è semplice per il server riconoscerli tutti.

DOM-based XSS

DOM: l’HTML della pagina viene salvato all’interno di document.body, ma ci sono altri campi del DOM (es.:

document.URL, document.location, document.referrer) che contengono altre informazioni. Un’attaccante

potrebbe scrivere allora degli script riferiti a questi altri oggetti.

DOM-based XSS: attacco cross site scripting in cui l’attaccante mira a modificare il DOM nel browser della

vittima attraverso l’esecuzione di uno script lato client. In questo modo la pagina non cambia, ma lo script

dell’attaccante viene comunque eseguito.

Es.: codice conteneste uno script che permette all’utente di selezionare la propria lingua preferita. Una di

queste opzioni viene scelta di default, pertanto, la richiesta della pagina corrisponde alla seguente URL:

http://www.some.site/page.html?default=French

L’attaccante manda invece il seguente link alla sua vittima:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

Quando la vittima clicka sul link, il browser manda la richiesta al server, il quale risponde inviando

page.html, la quale contiene lo script di scelta della lingua. Il browser crea quindi l’oggetto DOM associato

alla pagina ed inserisce, all’interno di document.location, il link inviato dall’attaccante. Infine il browser

esegue gli script, compreso quello contenuto in document.location, il quale recupera il cookie.

Cross Site RequestForgery (XSRF)

Obiettivo dell’attaccante: eseguire malware verso un sito web utilizzando i permessi di un determinato

utente.

Per questioni di sicurezza si potrebbe bloccare l’accesso a document.cookie, in questo modo l’attaccante

non sarebbe più in grado di rubarlo. È però sempre possibile impersonificare l’utente: invece che inviare

uno script per prendere il cookie se ne può inviare uno che faccia direttamente le operazioni che

l’attaccante vuole svolgere sul sito con i permessi di quell’utente (es.: effettuare un bonifico bancario).

Due modalità:

 Reflected XSRF: la vittima deve visitare il sito web dell’attaccante, il quale contiene delle azioni

nascoste verso il sito target. Contemporaneamente, la vittima aver stabilito una connessione sicura

verso il sito target, così che le operazioni svolte dallo script dell’attaccante arrivino al server passando

attraverso a questa connessione sicura.

 Stored XSRF: l’attaccante mette la sua pagina all’interno del server. Quando un client visita la sua

pagina, il browser del client viene rediretto verso il server trusted e le operazioni inserite

dall’attacante vengono eseguite come se arrivassero da quel client.

Underground Economy

Introduzione

Negli ultimi anni si è potuta notare una notevole diversificazione del mercato nero associato ai malware ed

alla sovversione di sistemi connessi ad Internet, dalla creazione alla monetizzazione. Il cuore di questo

ecosistema risiede nel contagio di computer-vittime. In particolare ha acquistato importanza un servizio

chiamato Pay-Per-Install (PPI), il quale provvede un modo per esternalizzare (pagare qualcuno per fare

qualcosa) la disseminazione globale del malware.

L’ecosistema PPI è costituito da tre attori:

 Clienti: entità che vogliono installare il loro malware su un numero di target host (non hanno un

vettore di infezione, ma cercano qualcuno che diffonda il malware per loro).

 PPI provider (o services): viene pagato dai clienti per installare il loro malware sui target host

(permette anche di scegliere una regione geografica). Per far ciò sviluppa un programma, chiamato

downloader, che quando viene installato recupera l’eseguibile del cliente e lo esegue. Il PPI provider

potrebbe fare lui stesso l’installazione, oppure pagare una terza parte (affiliati) per distribuire il

downloader.

 Affiliati: vengono pagati dal PPI provider per ogni host su cui riescono ad eseguire il downloader del

provider. Una volta che il downloader viene eseguito, si connette al PPI provider per scaricare il

malware del cliente.

Se un antivirus riuscisse ad individuare e a bloccare uno qualsiasi dei programmi della catena, l’installazione

del malware non avverrebbe con successo. Pertanto, sia i PPI provider che i clienti devono creare degli

eseguibili che agiscano di nascosto. Per far ciò utilizzano dei programmi detti packer venduti da terze parti.

Infiltrazione nell’infrastruttura PPI

Al fine di studiare l’infrastruttura PPI sono state portate avanti delle azioni di infiltrazione in quattro di

questi sistemi.

1. Milking PPI Services

Un downloader PPI ha tre compiti principali da svolgere:

 Scaricare il malware del cliente

 Eseguire il malware

 Comunicare al PPI service che l’installazione è avvenuta con successo

Gli infiltrati hanno costruito dei loro programmi, detti milker, che imitano la comunicazione di rete utilizzata

dai downloader al fine di scaricare i malware dei clienti, ma che non implementano le altre due funzionalità

(l’esecuzione del malware e la comunicazione dell’installazione).

Ciascun PPI downloader usa diversi metodi per scaricare il malware del cliente, tuttavia questi sono

riducibili a due classi principali:

 Downloader basici: usano HTTP e possiedono un set di URL hardcoded che forniscono il programma

del cliente

 Downloader avanzati: contattano una infrastruttura e da essa ricevono la lista delle URL da cui

scaricare il programma dell’utente. Anche questi usano HTTP per scaricare il programma.

I PPI services cambiano spesso le URL di download per evitare che vengano bloccate in delle blocklist.

2. Esecuzione dei malware

I milker sono stati eseguiti all’interno di una farm di contenimento di malware, una infrastruttura protetta

che permette di controllare l’esecuzione dei programmi. In particolare è stato monitorato il traffico di rete,

bloccando tutte le connessioni di rete e ridirigendole verso a dei sink server interni alla farm, eccezion fatta

per le connessioni al DNS.

3. Classificazione dei malware

I malware eseguiti sono stati classificati in base al traffico di rete che producono.

Caratteristiche di rete analizzate:

 Protocolli usati

 Lista di end point con cui il software comunica

 Lista di porte TCP/UDP di destinazione

 Caratteristiche di payload

Sono stati così individuati 57 cluster di cui 35 individuabili con un tag.

PPI business

Distribuzione geografica

Per la maggior parte delle famiglie di malware sono state osservate delle preferenze geografiche:

 Europa e Stati Uniti

 Stati Uniti o altri paesi singoli

 Nessuna particolare preferenza geografica

Ci sono vari fattori per cui un cliente dovrebbe scegliere un determinato paese: la classe di attività del

malware, il prezzo (varia in base al paese in cui si vuole installare il malware) e limiti legali.

Interazioni tra affiliati e PPI services

Capita non di rado che un affiliato sia esso stesso un cliente di un PPI service: l’affiliato cerca di guadagnare

sulla differenza di prezzo che i PPI service pagano per una determinata regione (es.: PPI 1 compra 1000

installazioni in Grecia per 60$, mentre PPI 2 le vende per 40$).

Download tree

Un downloader non si limita a scaricare l’eseguibile del cliente, ma si porta dietro una catena di download,

rappresentabile attraverso un albero:

 I nodi rappresentano i programmi

 Gli archi indicano quali programmi sono stati installati da un unico programma padre.

Android Security

Android

Android è un sistema operativo open source per smartphone, sviluppato da Google e basato su Linux. Nel

suo campo è il sistema operativo più diffuso (ricopre il 60% dei dispositivi mobili) e per questo è anche il più

attaccato (rapporto tra malware Android e malware di altri sistemi mobili del 9:1).

Il principale problema di sicurezza di Android è la frammentazione: il sistema operativo e l’hardware sono

fatti da due entità diverse, ciò implica che siano largamente diffuse versioni non recenti del sistema

operativo (aggiornare il sistema operativo non è priorità del vendor). Inoltre esistono moltissimi modelli di

smartphone di molti produttori diversi, tutti che girano lo stesso sistema operativo. Non è ovviamente

possibile ottimizzare il sistema operativo per ciascun modello.

Rooting del device: di solito gli smartphone vengono venduti senza la possibilità di accedere ai privilegi di

amministratore (sono pensati per tutti, anche per chi non è specializzato), tuttavia è possibile acquisite tali

permessi (l’utente diventa root).

Vantaggi a livello di configurazione:

 Sostituzione della ROM originale (es.: per disinstallare software promozionale)

 Regolazione del comportamento dell’hardware (es.: frequenza della CPU)

 Personalizzazione del software

Svantaggi:

 Tutte le applicazioni installate girano con i privilegi di root

 In caso di attacco, anche l’attaccante ha i privilegi di root

Architettura Android a strati:

 Kernel Linux

 Librerie di funzionamento

 Android runtime: le applicazioni Android sono scritte in Java e comunicano con questa porzione del

sistema per poter funzionare

- Librerie core

- Java Virtual Machine

 Application framework: gestione delle applicazioni

 Applicazioni vere e proprie

Le applicazioni Android sono suddivisibili in quattro categorie:

 Activitie: classiche applicazioni utente definite attraverso un’interfaccia grafica

 Broadcast Receiver: applicazioni che richiedono l’intento di ricevere particolari messaggi (ricevono

input dai diversi canali di comunicazione

 Content Provider: condividono dati tra più applicazioni

 Service: applicazioni senza UI che vengono eseguite in backgroud

Permessi App

Ogni applicazione viene eseguita all’interno di una sandbox e possiede un sistema di permessi simile a

quello di Linux.

Ogni applicazione nel momento dell’installazione richiede un elenco di Access Permission Label (ogni

componente del dispositivo ne ha una) che ritiene necessarie per l’esecuzione, ovvero richiede all’utente di

darle il permesso di accedere a quelle risorse. Una volta che l’utente accetta, l’app viene configurata in

modo tale che possa accedere alle risorse attraverso il sistema di permessi di UNIX.

I permessi Android sono controllati da tre principali oggetti:

 API Permission: permessi che vengono controllati per l’accesso alle risorse tramite Android

Framework (definiti dalle API chiamate). Questi permessi vengono controllati runtime

 File System Permission: permessi utilizzati per l’implementazione della sandbox e servono per

defiinire l’accesso alle risorse sul file system

 IPC Permission: permessi relativi alla comunicazione tra differenti applicazioni. Ogni app definisce

anch’essa un Access Permission Label e per comunicare tra loro devono utilizzare il protocollo Binder.

Caso Kakao Talk

Kakao Talk è un client di messaggistica istantanea in voga nella comunità tibetana famoso per essere stato

oggetto di un attacco volto a rubare i dati personali degli utenti.

Gli attaccanti hanno diffuso un messaggio di posta elettronica contenente l’applicazione maligna, ovvero

una copia dell’applicazione originale, ma che richiedeva una notevole quantità di permessi sul telefono.

Accade spesso che gli utenti accettino i permessi senza leggerli o senza chiedersi se siano ragionevoli, in

questo modo l’applicazione è stata in grado di memorizzare la rubrica dell’utente, la cronologia degli SMS

ed il registro delle chiamate, per poi contattare un server per salvare informazioni come URL e credenziali

utilizzate dal telefono. Inoltre intercettava SMS ed inviava coordinate GPS per geolocalizzare il device.

Sistemi di difesa

Google Bouncer

Google Bouncer è un sistema di scansione automatica delle applicazioni pubblicate sul Play Store.

Tecniche di scansione:

 Analisi statistica delle applicazioni per ricercare minacce note

 Esecuzione del software in un emulatore virtuale

 Analisi dei dati immessi nel sistema da parte degli sviluppatori

Google Bouncer è stato soggetto ad un’analisi di sicurezza da parte di alcuni ricercatori che ne hanno

dedotto il comportamento:

 Analisi dell’applicazione inviata allo store

 Ricerca di pattern sospetti all’interno dell’app

 Interazione automatica con l’interfaccia grafica

 Controllo della provenienza delle app solo da certi indirizzi di rete

 Utilizzo di blocchi di rete ben definiti

È stata poi sviluppata un’applicazione in grado di eludere i meccanismi di controllo del Bouncer, tale ha le

seguenti caratteristiche:

 Quando riconosce un blocco di rete adibito al Bouncer disabilita le sue funzionalità

 All’inizio non ha funzioni JavaScript, ma le scarica automaticamente quando viene installata

 Ha in più delle funzionalità benigne che richiedono dei permessi

Problematiche del Bouncer:

 Code coverage non totale: non è possibile controllare tutto il codice

 Facilità di rilevazione dell’emulatore

 Gli IP dei dispositivi sono blocchi fissi

SELINUX

Security Enhanced Android SELINUX: sistema che permette di impostare dei permessi più sofisticati. Tali

possono anche essere settati dinamicamente.

Di default si nega ogni permesso esplicito, soprattutto per le applicazioni system (che girano a più basso

livello).

Il sistema avrà poi due principali repository:

 Permission repository: contiene i singoli permessi richiesti e gli insiemi dei permessi concessi

dall’utente

 Policy repository: contiene i pattern riconosciuti come dannosi

Tale sistema presenta comunque alcune debolezze:

 Alcune sequenze dannose sono invece lecite (falsi positivi)

 Necessità di aggiornare costantemente il policy repository

 Non copre tutto lo spettro di attacchi

CopperDroid

CopperDroid: piattaforma per l’analisi dinamica di malware basato su tre principi:

 Analisi a basso livello (OS kernel) e ad alto livello

 Stimolazione delle applicazioni per raggiungere tutte le entry point del sistema e consentire code

coverage

 Testing su database di malware noti e scansioni via web di applicazioni segnalate da utenti

Questo sistema è invisibile alle applicazioni in esecuzione nel guest, non modifica il flusso di esecuzione e fa

analisi approfondita delle chiamate tra le applicazioni (IPC), controllando la comunicazione tra esse.

Native Client

Introduzione

Native Client è una sandbox che permette di eseguire codice nativo (es. C, molto pericoloso) all’interno del

browser.

Motivazioni:

 Performance maggiori dei linguaggi di basso livello

 Esistenza di legacy code (codice sorgente correlato ad un sistema operativo non più in produzione)

 Utilizzo di altri linguaggi diversi da Java

Un’applicazione è composta sia da componenti trusted che da componenti untrusted. In genere c’è

un’interfaccia utente implementata in JavaScript eseguita nel browser ed una porzione di codice scritta in

codice nativo che gira all’interno della sandbox NaCl (Native Client). Sia il JavaScript che il codice nativo

sono untrusted, ma sono eseguite nel browser e nella sandbox che sono trusted.

Come si fa ad assicurare del codice nativo?

 Fidarsi dello sviluppatore facendo firmare il codice per sapere che arriva da sorgenti trusted

 Attraverso sistemi di OS/HW isolation: sandbox implementate a livello di sistema operativo. Tuttavia

un sistema operativo è molto ampio e potrebbe quindi avere un’ampia interfaccia di attacco. Inoltre,

ogni sistema operativo ha la sua sandbox

 Progettare una nuova sandbox da zero: soluzione migliore

Il codice nativo arriva al browser in binario: si fa un primo controllo già sul binario stesso.

Safety:

 Evitare o controllare operazioni unsafe

 Memory boundry: impedire al codice di uscire dalla zona in cui è confinato

Tipologie di istruzioni:

 Safe: istruzioni che non fanno operazioni di memoria (es: operazioni aritmetiche)

 Unsafe: memory access, istruzioni privilegiate, system call, …

 Critiche: jump:

- Dirette: viene indicato l’indirizzo dove saltare direttamente nel binario

- Indirette: l’indirizzo dove saltare è salvato all’interno di un registro (jump %eax), pertanto il

valore effettivo sarà conosciuto solo in fase di esecuzione

Un salto è legittimo se non esce dallo spazio di indirizzamento del Native Client.

Il codice nativo deve poter fare delle system call, ma sono delle istruzioni unsafe. Viene dunque predisposto

un trustedenviroment contenente le system call. Se il codice ha bisogno di farne una deve chiedere al

trustedenviroment.

L’esecuzione del binario avviene in una zona di memoria ben definita e bisogna impedire che possa saltare

ad una zona di memoria esterna. Vengono quindi controllare tutte le istruzioni per controllare che siano

safe.

Potrebbe accedere che una jump non esca dalla zona di memoria adibita al binario, ma potrebbe non

puntare all’inizio di un’istruzione, bensì in mezzo, andando a creare nuove istruzioni non viste dallo

scanning lineare. C’è però un problema in caso di jump indirette: non si sa quale sia il valore del registro

%eax (si conosce il valore solo in esecuzione).

Le celle sono tutte di dimensioni diverse, ma è possibile uniformarle prendendo la dimensione della cella

più grande (32 bit nelle architetture Intel x32) e far sì che tutte le istruzioni abbiano tale dimensione,

aggiungendo NOP (No OPeration) fino a riempire i bit mancanti (padding). Per fare questa operazione si

utilizza una maschera:







In tal modo la jump può saltare solo ad un’istruzione a 32 bit (se non fa così viene allora forzata). Questa

operazione viene chiamata pseudo instruction.

Proprietà del binario:

1. Il binario non è scrivibile

2. Il linking deve partire da 64k

3. Le indirectjump devono essere pseudo instructions (AND e JMP atomica)

4. Tutte le istruzioni devono essere raggiungibili dal motore disassembly

5. Tutti i salti diretti devono essere anch’essi allineati

6. Quando è finito il binario, questo deve terminare con un’istruzione di ALT

Per evitare che si esca all’esterno, è necessario restringere la visione che il Native Client ha della sua

memoria. è possibile fare quindi uso della segmentazione (caratteristica Intel).

SegmentDescriptionTable: ogni linea della tabella definisce una zona di memoria (segmento). Si crea quindi

un segmento apposito per il binario (si definisce base e lunghezza del segmento). Quando un processo

cerca di uscire dal suo segmento viene bloccato dall’hardware.

È possibile fare jump verso il trustedenviroment, ma attraverso un trampolino: il binario salta al

trampolino, il quale esegue l’istruzione richiesta e ritorna poi al binario.

Sommario

1. Storia della Computer Security ...................................................................................................................... 1

3. Fondamenti della Computer Security ............................................................................................................ 2

6. Reference Monitors ....................................................................................................................................... 5

4. Identificazione e autenticazione.................................................................................................................... 8

7. Unix Security ................................................................................................................................................ 11

10.a Attacchi software ..................................................................................................................................... 15

10.b Difese software ........................................................................................................................................ 19

14. Crittografia ................................................................................................................................................. 21

17. Network Security ....................................................................................................................................... 25

16. Communications Security .......................................................................................................................... 31

18. Web Security ............................................................................................................................................. 36

Underground Economy ................................................................................................................................... 41

Android Security .............................................................................................................................................. 44

Native Client .................................................................................................................................................... 47